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

migrate to npm@7 #274

Closed
zackschuster opened this issue Oct 30, 2020 · 3 comments
Closed

migrate to npm@7 #274

zackschuster opened this issue Oct 30, 2020 · 3 comments

Comments

@zackschuster
Copy link
Collaborator

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 from yarn and pnpm) 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 for yarn 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 that npm@7 doesn't and/or can't:

  • autoclean
  • human-readable lockfiles
  • simplified command-line interface
  • resolutions in package.json
  • overall workspaces support

we 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 believe yarn is better overall (heck, i may never stop calling yarn publish if npm 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 than yarn's; for a given repo, they're 3-4x larger and seemingly impossible to hand-prune. to put it differently: it's easy for package-lock.json to eclipse 1mb (!!), while it's hard for yarn.lock to eclipse 500kb. nonetheless, npm@7 also supports yarn.lock, though apparently the yarn@2 variant, which is slightly different but basically the same, so perhaps if we merely wait for the glorious corepack future to arrive we can skip all this & pretend it never happened.

that's basically all my thoughts (absent dialogue).

@eleith
Copy link
Owner

eleith commented Oct 31, 2020

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.

@zackschuster
Copy link
Collaborator Author

yeah, it strikes me as more of a looming inevitability than any sort of immediate mandate, especially since npm@7 is currently only available as the default on two releases in node@15 (which will never go LTS by design).

you're right that npm publish vs yarn publish doesn't affect us either; i only mean it as an example for why i think yarn has better UX overall.

overall, i agree that our setup works well currently & we can afford to wait and see how things further shake out.

@zackschuster
Copy link
Collaborator Author

closing this as corepack is part of node now and, contrary to my expectation that corepack would provide a yarn-shaped shim for npm, it just straight-up installs yarn et al 😝 with such a blessing having been given, i doubt there's any need for us to make a change.

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

No branches or pull requests

2 participants