-
Notifications
You must be signed in to change notification settings - Fork 358
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
Upgrade to yarn 3 #7903
Comments
@Fryguy 'cross-repo-test(s)' command is only valid on pull requests, ignoring... |
This issue has been automatically marked as stale because it has not been updated for at least 3 months. If you can still reproduce this issue on the current release or on Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation. |
This issue has been automatically closed because it has not been updated for at least 3 months. Feel free to reopen this issue if this issue is still valid. Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation. |
Right now we are using yarn 1.22, however newer versions of yarn have been out for a while, with yarn 3.0.2 being the latest. yarn 3 changes things, but not as dramatically as one might think. We can use the
nodeLinker: node_modules
mode to move forward but keep backward compatibility until we can move towards Plug'n'Play.See also https://yarnpkg.com/getting-started/migration. The goal is to get to Plug'n'Play mode, but the first step is to upgrade yarn. After that we have to fix the dependency warnings and any direct calls to node_modules.
Some things to note in these changes.
yarn now uses a project-committed version of yarn as opposed to a global version (the global is only used to kick off the project-committed version). There are pros and cons, IMO, but you will see a yarn-3.0.2 file installed in each repo. Upgrades are pretty easy though, by just running
yarn set version latest
then committing the changes, so we can create a blaster-outer script for that.I've opted for the global cache as opposed to a project specific cache. Due to the way we use git repositories, the gem repo is effectively recreated on new pulls, so this should help with avoiding re-downloading all of the node modules.
Installation time is surprisingly not that much faster with the cache, because of the need to still create the node_modules directories. Once we move to Plug'n'Play, however, that should minimize greatly.
The new format is so much nicer on your eyes 😉
Must be merged / tested together:
Should be merged with the others
Technically optional, but would be good to get all of our dependencies to the same level
The text was updated successfully, but these errors were encountered: