-
Notifications
You must be signed in to change notification settings - Fork 440
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
Use npm instead of Yarn #3173
Use npm instead of Yarn #3173
Conversation
Thanks for this work @alanorth ! I can see we'll need to do more work here to update other areas where I've linked this over to the 9.0 brainstorms we've started gathering for Steering to discuss. I see this as a task which can help with the "Easier Installation" idea (by removing a prerequisite in yarn). @artlowel and @atarix83 : I added you both as reviewers here as I'd appreciate your feedback on this idea. I'd be willing to help @alanorth to get the GitHub Actions / Docker scripts updated, assuming we all agree with the goal of removing usage of |
I like this idea a lot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alanorth!
I agree, getting rid of yarn 1 is a good idea.
This PR does seem to break our lint step (On github you see the yarn version, but I get the same issue running lint with npm). Since it won't compile, perhaps eslint resolves to a different version now?
You can get rid of the resolutions section in package.json, it's something unique to yarn, to force to use a certain version of a dependency when there are conflicts. Since the project builds fine, it looks like these particular resolutions are no longer necessary anyway.
I do think we should add the npm equivalent, which is called overrides, and solve any conflict we have with peerDependencies in there, rather than instructing people to run npm install
with --legacy-peer-deps
We'll also need to update the github workflows to use npm instead of yarn, as well as the Dockerfile
Thanks @artlowel!
Oh I'm not sure, that needs more investigation. Appreciate any advice.
Done, thanks.
Oh that is nice to know. I have worked through the conflicting dependencies and added overrides for each. Now we can install with
Ah yes, true. Should be easy. I will take a look soon. |
Hi @alanorth, |
Hi @alanorth, |
@alanorth I fixed the lint errors with an update to the unused-imports plugin (this was causing the problem, not the spec test itself) - doc: |
Hi @alanorth, |
Instead of using the Yarn link protocol, we can use npm's built-in support for local dependencies using "file:".
Thanks @kshepherd! You're right, the eslint-plugin-unused-imports say this:
We are using 2.x.x currently, but according to this we should be using 3.x.x. It fixes the lint error, though I'm not sure why we don't hit that issue with yarn. 🤔 |
All scripts should use "npm run" instead of "yarn".
Now that we are using npm we need to commit this.
These are a yarn-specific concept that we don't need for npm.
Add overrides for conflicting peer dependencies. In yarn these were handled less noisily, but in npm we need to add explicit overrides for each. This allows us to use `npm install` without forcing or using `--legacy-peer-deps`.
7610a49
to
d9be88d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alanorth!
This is looking good to me now, I have one more minor inline comment.
It would be good if someone with more experience with Docker could give those changes a more thorough test though
Use npm instead of yarn in GitHub Actions.
Fix error in lint: > lint/src/util/structure.ts:16:20 - error TS2314: Generic type 'RuleMetaData<MessageIds, Options>' requires 2 type argument(s). > > 16 export type Meta = RuleMetaData<string>;
Fix lint error. According to the docs we should be using v3.x.x: > * Version 3.x.x is for eslint 8 with @typescript-eslint/eslint-plugin 6 - 7 > * Version 2.x.x is for eslint 8 with @typescript-eslint/eslint-plugin 5 See: https://www.npmjs.com/package/eslint-plugin-unused-imports
There is a minor difference in syntax when starting the application with `npm run serve`. We use `--` to make sure npm doesn't try to parse the `--host 0.0.0.0` as an option, allowing it instead to be read by Angular CLI (ng). Also, there is no direct npm equivalent to yarn's --network-timeout option so I will remove it. If we need something similar later we might be able to use these config options: npm config set fetch-retry-mintimeout 300000 npm config set fetch-retry-maxtimeout 300000
This was the only Angular package not using a "^" to specify the semver range.
We need this now that we are using npm instead of yarn.
Use npm instead of yarn.
Use npm instead of yarn. Mostly a search and replace, minus some changes in terminology, for example "yarn add" vs "npm install".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 looks good, tests well (I use docker and all seems good in my environment), thanks @alanorth
Thanks for testing @artlowel and @kshepherd. This is at +2 now. As far as I can see the only thing remaining is to update the DSpace wiki, though the section for DSpace 9 doesn't exist yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Thanks @alanorth ! This was waiting on me to do a quick review. This looks GREAT! It's working well for me. I noticed on minor thing (and already fixed it), where the yarn.lock
should now be listed in our .gitignore
and .dockerignore
in order to ensure it's no longer added back to our codebase.
Overall, this is ready to merge for 9.0. I'll leave the needs documentation
flag in place until we create the new 9.0 wiki space, as we'll need to (eventually) update the docs there.
References
Description
Simplify the project by using npm (which ships with Node.js) instead of Yarn (an extra global dependency and prerequisite).
The original reasons for using Yarn (dependency install speed and robust lockfiles) are no longer as compelling. In the past few years npm has improved in both of these areas. Furthermore, we are using Yarn 1.x "classic", which has been deprecated for several years and migration to Yarn 2, which is not backwards compatible, will require us to do some work anyway.
Instructions for Reviewers
Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.
List of changes in this PR:
yarn.lock
package.json
to usenpm run
for all scriptspackage-lock.json
README.md
with new instructions fornpm
Include guidance for how to test or review your PR.
Try installing dependencies and building the application in dev and production mode:
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!
npm run lint
npm run check-circ-deps
)package.json
), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.