Live data from Hacker News

Hello Yarn 2, Goodbye node_modules

freddixx.medium.com

31–40 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#31
post #20

This is probably a good direction, but it seems like it's still contributing to JS dependency management becoming even hotter of a mess. There really shouldn't be two standard package managers for JS. This also reminds me how much we keep reinventing the wheel on this. I know it's likely infeasible for various reasons but it seems like it would be great to have a language-agnostic package manager that worked more or…

> There really shouldn't be two standard package managers for JS.

Amen to this. This type of stuff leads to so much confusion especially for beginners. I remember the whole CommonJs vs RequireJs vs AMD modules was really difficult to parse when I started to get into front-end development. Yes having multiple choices lets us experiment with alternatives, but I think we underestimate the costs of complicating the ecosystem as a result.

Re: Hello Yarn 2, Goodbye node_modules

#32

I see absolutely no reason to upgrade. I don't have any problems with npm7 right now and I fail to see why I'd need to change all these things and learn a new tool. Maybe the patch thing. But to say that you eliminated node_modules and then introduce a new folder which will have the same files inside it... sounds like madness to me. No thanks.

That's the point, it's _not_ the same files. Instead of extracting 75K individual files on disk, the Plug 'n Play concept keeps every package as its zipped tarball on disk. So, N tarballs, one per package, instead of hundreds of files per package.

Conceptually, it's great. The problem comes when all the other tools in the ecosystem are still expecting a `node_modules` folder to exist and to be able to read those individual files directly, including Node itself.

From what I've seen, the compat story has improved over the last couple years, but there's still rough edges. Last time I tried it I ran into problems with things like import aliases, and of course VS Code and TypeScript and other tooling all had to be tweaked to work correctly with Yarn's filesystem overrides.

But, next time I start a new project from scratch, I'll probably give it another shot.

Re: Hello Yarn 2, Goodbye node_modules

#33
post #20

This is probably a good direction, but it seems like it's still contributing to JS dependency management becoming even hotter of a mess. There really shouldn't be two standard package managers for JS. This also reminds me how much we keep reinventing the wheel on this. I know it's likely infeasible for various reasons but it seems like it would be great to have a language-agnostic package manager that worked more or…

well for node not js. deno does not require a package manager nor does the browser. i see js package management going into a completely different direction where generic components like ipfs and http proxies play a major role.

Re: Hello Yarn 2, Goodbye node_modules

#34
post #20

This is probably a good direction, but it seems like it's still contributing to JS dependency management becoming even hotter of a mess. There really shouldn't be two standard package managers for JS. This also reminds me how much we keep reinventing the wheel on this. I know it's likely infeasible for various reasons but it seems like it would be great to have a language-agnostic package manager that worked more or…

well for node not js. deno does not require a package manager nor does the browser. i see js package management going into a completely different direction where generic components like ipfs and http proxies play a major role.

NPM and Yarn are both widely used for front-end JavaScript code, usually with Webpack or some other horror.

Deno is an interesting model, but maybe not widely applicable?

Re: Hello Yarn 2, Goodbye node_modules

#35
pnpm’s strategy of having a single global node_modules folder of cached deps it links to is still my favorite. Installs are way faster than both npm and Yarn, and it even works offline if you’ve ever installed the packages before. It’s supported workspaces long before npm, and works as a drop in replacement. I don’t like working without it these days.

I just want Vercel to support it so I can use it to speed up build times with relying solely on build cache.

Re: Hello Yarn 2, Goodbye node_modules

#36
I suppose I'm fairly unique in that I actually like node_modules.

I enjoy the simplicity of having a project level folder that has all the dependencies.

I like being able to easily expand it in my project tree and set a breakpoint in a dependency source file to debug strange issues.

For deployments, I like being able to see exactly what's being executed.

I would enjoy some more clear (to me) version locking though. I seem to constantly run into issues between environments with slight version changes, even though I commit my lockfile.

Re: Hello Yarn 2, Goodbye node_modules

#37
I just moved our ~50 repos + 4 highly complex applications to Yarn 3. It works well, with a few gotchas -

- In practice, using PnP and removing node_module creates more problems than it solves. Disk storage is cheap, so we use Yarn with "nodeLinker: node-modules"

- Some "core" functionality like "yarn outdated" and "yarn install --production" is no longer available by default, and you need external plugins to mimic it

- Custom pre/post hooks in package.json are not supported. So if you have "prestart" or "postrelease", that will no longer run automatically.

But overall, it works well. We chose Yarn over NPM because we often use its "resolutions" feature that NPM has not yet implemented.

Re: Hello Yarn 2, Goodbye node_modules

#38
post #20

This is probably a good direction, but it seems like it's still contributing to JS dependency management becoming even hotter of a mess. There really shouldn't be two standard package managers for JS. This also reminds me how much we keep reinventing the wheel on this. I know it's likely infeasible for various reasons but it seems like it would be great to have a language-agnostic package manager that worked more or…

> ere really shouldn't be two standard package managers for JS.

Why? Aren't there multiple package managers in many languages? SBT/Maven, Ant/Ivy/Maven, PIP/Poem(or poetry or whatever it is). What's the harm?

Re: Hello Yarn 2, Goodbye node_modules

#40
I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to go into the new .yarn folder but its just not the same.

Sure, node_modules is a behemoth and there is still a likely better way - but I _love_ having all of my packages on a per-project basis. I used to be a user of Yarn 1 and 2, and their debugging and installation system is insanely better than NPM's, but I quite like having everything in one place for every project.

Post reply on HN