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
migrate to npm@7 #274
Comments
thanks for the informative post. with github's acquisition of npm, and npm's pervasiveness, i'm generally in favor of npm as a default for node projects, particular when developing a node module. for now though, i think we have something that works and with some minor advantages. it also seems rather trivial to remove yarn usage should we want to make a hard switch. i'm still able to publish using npm. if that were to break one day, i imagine that would push for the need for change. unclear. |
yeah, it strikes me as more of a looming inevitability than any sort of immediate mandate, especially since you're right that overall, i agree that our setup works well currently & we can afford to wait and see how things further shake out. |
closing this as |
it seems apparent that
npm@7
is the future, thanks to all its feature additions & general performance improvements (at last! it no longer feels like a dying dog delivering a bundle of newspapers!), while efforts like corepack (driven by core maintainers fromyarn
andpnpm
) will cover the competitive gap from within node itself.as such, i feel we should switch this repo over at some point (
npm@7
in LTS?) to keep abreast with the ecosystem. since i was the one who initially pushed foryarn
in the repo, this might not even be a conversation; nonetheless i'll share my perspective as thoroughly as i can, at the very least for completeness' sake 😄yarn@1.22.5
(the version i use) is still excellent & offers certain UX advantages thatnpm@7
doesn't and/or can't:autoclean
resolutions
inpackage.json
workspaces
supportwe don't currently use
resolutions
&workspaces
will probably never affect us, so those aren't important to consider.the cli — while drastically better now — is still clunky for
npm
but it's not a big deal. it has its own merits, even if i still believeyarn
is better overall (heck, i may never stop callingyarn publish
ifnpm
doesn't copy its behavior).autoclean
saves us nearly 40mb on disk, turning a 97mb development install into a 60mb one (mostly from dead code in the typescript sdk 🙄). that's meaningful to me, at least aesthetically, but it is "only" 40mb, so perhaps this is moot.the lockfiles are the biggest gripe for me, because
npm
's are just so much more bloated thanyarn
's; for a given repo, they're 3-4x larger and seemingly impossible to hand-prune. to put it differently: it's easy forpackage-lock.json
to eclipse 1mb (!!), while it's hard foryarn.lock
to eclipse 500kb. nonetheless,npm@7
also supportsyarn.lock
, though apparently theyarn@2
variant, which is slightly different but basically the same, so perhaps if we merely wait for the gloriouscorepack
future to arrive we can skip all this & pretend it never happened.that's basically all my thoughts (absent dialogue).
The text was updated successfully, but these errors were encountered: