Live data from Hacker News

Hello Yarn 2, Goodbye node_modules

freddixx.medium.com

61–70 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#61
post #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?

IMO, npm is a breeze compared to pip. With npm you know that `npm i && npm start` will start 95% of the projects cross-platform. It allows having different subdependencies versions in a way that just works. It encourages semver but at the same time you have lock file. Is highly customizable with rc files.

Perhaps I just don't have that much experience with pip, but it feels more like a tool to install packages, then you're on your own with some makefile or python scripts with no standard setup.

Re: Hello Yarn 2, Goodbye node_modules

#62
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's a joke in java where you have the Maven and the Gradle logos. And then two arrows, one point from one to another in a circle. With the title "java upgrade path"

Re: Hello Yarn 2, Goodbye node_modules

#63
post #60
post #53

Earlier quoted context omitted.

Bundling is still required to avoid HTTP waterfall that would ensure if you load raw ES modules from the browser. A real-world frontend codebase will include 100-1000+ files (via transitive dependencies), and you do not want 100+ sequential HTTP request even over HTTP2. You might not need to transpile your app (via babel), but you still need to bundle it (via webpack/rollup/parcel/esbuild/swc/etc)

Lol, yeah, I thought I’d use snowflake to debug and build my app. It worked perfectly fine out of the box, which was impressive. Unfortunately loading my app went from a second to half an hour (I think it just broke loading all the files somewhere).

I think snowflake has a hybrid mode, where you bundle dependencies and not your application code. But, I’ve been blocked by React not working well with ESM

Re: Hello Yarn 2, Goodbye node_modules

#64
post #44

Earlier quoted context omitted.

Isn't the first party solution NPM?

The first-party solution is ES Modules. Node is not Javascript.

ES Modules aren't package management though? In that ES Modules say nothing about how to get the modules in the first place, nor anything about versions. Not in any standardized way anyhow.

Re: Hello Yarn 2, Goodbye node_modules

#65

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…

I too like node_modules. What's nice is you can use Yarn 3 and keep node_modules by setting the https://yarnpkg.com/configuration/yarnrc#nodeLinker config option.

Re: Hello Yarn 2, Goodbye node_modules

#66
post #58
post #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…

I think pnpm retains your node_modules folder, but always has only a single copy of each package version on disk. I like that.

Yeah pnpm's approach to node_modules is really pretty elegant. It supports pnp too.

Re: Hello Yarn 2, Goodbye node_modules

#67
post #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?

I cannot make any sense of how to use packages in python. So I just don't. I don't use python all that much, but if it was easy and obvious what was the right way to do it, maybe I would. But in the rare cases that I write python, I write zero-dependency code. Or maybe I download a library and just manually copy it to a file.

At least one time, I tried to get into python packages, but I recall there seemed to be about a half a dozen methods for doing it at the time. I didn't try very hard.

Re: Hello Yarn 2, Goodbye node_modules

#69
post #17

Last time I tried, yarn 2 was totally unusable. Apparently, it would work in a future world where all packages in the registry were perfect. Has that future arrived?

My experience is that Yarn v2 works great as long as you stick with the `node_modules` linker. It's the "Plug 'n Play" functionality that is great in theory but still rough in practice. I've been using Yarn v2 on a decent-sized mixed-codebase JS app since the fall, and we just switched over to using it for both of the Redux Toolkit and React-Redux repos.

Thanks. I'll try with node-linker

Re: Hello Yarn 2, Goodbye node_modules

#70
post #42
post #38

Earlier quoted context omitted.

> 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?

There are I'm sure valid reasons for doing it, but it fragments an already fragmented ecosystem. And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler, Rust/Cargo, Swift/SPM, etc.

> And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler

Bundler, AFAIK, isn't first-party, its a separate team and project.

Historically, IIRC, gems wasn't even first-party

Good standard solutions are often the outcome of multiple competing efforts pushing forward, proving what works, and proving what doesn't.

Post reply on HN