Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: upgrade to yarn 4 #2697

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open

Conversation

DhariniJeeva
Copy link
Collaborator

@DhariniJeeva DhariniJeeva commented Feb 21, 2025

Description

Jira This PR upgrades yarn from 1 to 4.

pipeline
PR here

NOTE: This migration is done by committing the binary file instead of using corepack as committing the binary and accessing it via yarnPath seems like the safest/simplest option given the state of corepack support from node.(nodejs/node#51981)

Screenshots (if appropriate)

How to Test

  • check out this repo locally
  • run npx npkill -D -x -y [to remove all node_modules]
  • run yarn install

Checklist

  • [ ] I have added before and after screenshots for UI changes
  • [ ] I have added JSON response output for API changes
  • [ ] I have added steps to reproduce and test for bug fixes in the description
  • [ ] I have commented on my code, particularly in hard-to-understand areas
  • [ ] My changes generate no new warnings
  • [ ] I have added tests that prove my fix is effective or that my feature works

@DhariniJeeva DhariniJeeva requested a review from a team as a code owner February 21, 2025 03:10
Copy link

vercel bot commented Feb 21, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
boundary-ui ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 26, 2025 2:57am
boundary-ui-desktop ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 26, 2025 2:57am

@@ -137,21 +137,5 @@ module.exports = {
});
});
},
packageAfterPrune: async (_, buildPath) => {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we are pinning node-gyp v10, we don't need this workaround anymore, I tested it, but lmk if there's anything I missed

Copy link
Collaborator

@hashicc hashicc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! I have a few comments/suggestions to consider. I'm looking forward to the nicer things we get with yarn 4. ⚡⚡⚡ Just as a rough benchmark it looks like it's twice as fast from a cold install


nodeLinker: node-modules

yarnPath: .yarn/releases/yarn-4.6.0.cjs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about not pushing for corepack if it's unlikely to be used with node in the future. Is this method of vendoring yarn preferred over a community github action? Vendoring could be a good approach approach, I'm just wondering how do we would go about updating (and verifying) the vendored file in the future?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm googling this feedback

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of doing manual updates, the local installation says whenever there is a new yarn update and that can be a good indicator to update yarn. Are you thinking of other alternatives that we can use in place of corepack? I did not investigate other options but might be worth considering in the future

@hashicc
Copy link
Collaborator

hashicc commented Feb 21, 2025

There's two yarn links in the root README.md that could be updated to the modern docs. A mention in the readme that we're using yarn 4 might be useful since my assumption is many javascript projects didn't make the jump so people might still be accustomed to yarn 1.

Comment on lines -12 to -13
"nohoist": [
"**/electron**"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we still planning on no hoisting? I realize now that this probably wasn't even working correctly as I'm not sure that glob was accurate and I think some electron packages moved namespaces to @electron at some point which we never updated

I also don't have context as to why we needed to nohoist them in the first place so I'm guessing we might not even need it

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does not look like we need to do the equivalent of nohoist in yarn 4, I tested it with and without in both yarn 1 and yarn4 and did not see any issue so my guess is that it is not needed.

Copy link
Collaborator

@laurenolivia laurenolivia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work. Smoke tested this locally, and it did not generate any warnings 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants