-
Notifications
You must be signed in to change notification settings - Fork 29
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 #47
Conversation
thanks @nickmccurdy! why though? this removes any package lock mechanism 😅 |
This organization uses npm without a package lock for libraries, and with a package lock for apps. I'm just making pull requests to keep things consistent for contributors. |
Ah sorry I missed that discussion is there a link anywhere to the rationale? :) |
In the gitignores of other libraries:
https://github.com/testing-library/dom-testing-library/blob/master/.gitignore#L6-L7 I believe Kent has a more in-depth explanation somewhere but I couldn't find it. |
I see, thanks! I can understand the library dependency angle, but I'm not sure I agree with the rationale when working with devDeps that actually produce distributable assets like pptr-testing-library does though (which is much more similar to the app situation than library dependencies). Removing the lockfile here feels a bit like policy matching for the sake of policy matching rather than actually following the reasoning of the policy :/ How would you feel about replacing with a package lock? |
Are you referring to how dependent projects would install versions of pptr-testing-library dependencies? If so, it would be the same, as Personally I usually prefer using lock files, but it's not the preference of the organization it seems, and I think not locking dependencies can help with testing different installations in this situation. |
I'm aware of how lock files work :) I am not referring to dependent projects. pptr-testing-library in CI builds a bundle of javascript that is distributed as part of our own npm package. The lock file ensures that there are no unexpected changes to this bundle and given that we do string replacement and relatively hacky things to make this work, I am concerned that unexpected transitive dependency changes could result in breakages. I understand the spirit of the ban on lock files, that a library author should ensure their library can handle unexpected dependency versions that real users might install. This package goes out of its way to ensure we handle different versions, above and beyond what simply removing a lock file would do. Enforcing a lock file ban here would increase the volatility and reproducibility of published versions of this package while not actually reaping any of the stated benefits beyond the steps we've already taken. I appreciate that you're seeking consistency across the organization, but consistency in reasoning for positive outcomes should prevail over consistency for file existence. |
Alright, I'll add a lock file for npm in this case. We have two options, what would you prefer?
|
3228816
to
dc645f7
Compare
Thanks @nickmccurdy!
This sounds great :) |
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 @nickmccurdy! 🎉
01d1de8
to
a1d0c7c
Compare
This should work locally after running |
It seems like npm 7 is successfully installed now. Can we get another review please? |
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.
still LGTM :)
No description provided.