Reconfigured Yarn and package.json with more universal approach

[mkramek]

Summary

• Reconfigured .yarnrc.yml for universality and better compatibility
• Added support for engines field in package.json

Ticket ID/Link to ClickUp

Improve .yarnrc.yml configuration

Checklist

• Provided a screenshot (only if change is visible in UI)
• Provided a change scope in summary
• Local Docker build has passed

[hkrawczyk]

Task linked: CU-86azuzuv9 Improve .yarnrc.yml configuration

[ItsAdel]

Seems like we are maintaining another binary file in our repo with this update instead of the yarn4.1.1 binary.

Just don't want the hassle of maintaining binaries to fall on us later down the road. But if the team agrees this is the best approach, then we can just move forward with this change

we have a line "packageManager": "[email protected]" in package.json, is that not enough to enforce the correct yarn is being used?

[hkrawczyk]

Seems like we are maintaining another binary file in our repo with this update instead of the yarn4.1.1 binary.

Just don't want the hassle of maintaining binaries to fall on us later down the road. But if the team agrees this is the best approach, then we can just move forward with this change

we have a line "packageManager": "[email protected]" in package.json, is that not enough to enforce the correct yarn is being used?

I agree with @ItsAdel - let's not add a package manager to the repo, it's a strange practice.

[hkrawczyk]

please specify the version in package.json rather than get extra files in repo

[mkramek]

Seems like we are maintaining another binary file in our repo with this update instead of the yarn4.1.1 binary.

Just don't want the hassle of maintaining binaries to fall on us later down the road. But if the team agrees this is the best approach, then we can just move forward with this change

we have a line "packageManager": "[email protected]" in package.json, is that not enough to enforce the correct yarn is being used?

This specific binary is used specifically as a plugin, which is also mentioned in .yarnrc.yml under plugins section. The reason for that is Yarn 2+ completely and blatantly ignoring any package.json remarks, as known in this issue (Yarn issues page); they haven't added this feature natively yet, hence the plugin.

[ItsAdel]

This specific binary is used specifically as a plugin, which is also mentioned in .yarnrc.yml under plugins section. The reason for that is Yarn 2+ completely and blatantly ignoring any package.json remarks, as known in this issue (Yarn issues page); they haven't added this feature natively yet, hence the plugin.

My approach would be to leave out the binaries for now until this feature is natively needed. Strict enforcing of yarn 4.1.1 in our package manager is not necessary. Remove all that is causing the build to fail.

In our CI/CD pipeline (Dockerfile), we ensure the correct yarn file is being installed anyways.

# Replace legacy Yarn with modern one
RUN npm uninstall -g yarn
RUN corepack enable
RUN corepack prepare --activate yarn@stable

And in our local environment, our team is small enough to have this just in the documentation somewhere (README) or just be tribal knowledge.

I would steer away from over complicating it.

[mkramek]

I would steer away from over complicating it.

Makes sense, scratched that

[ItsAdel]

Not needed anymore I think

[mkramek]

Ah, f... I didn't see that comment. I guess I'll make a quick fix?