Live data from Hacker News

Hello Yarn 2, Goodbye node_modules

freddixx.medium.com

151–160 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#151
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…

Not to mention getting to avoid the nightmare that is Python's shared-library situation (with virtual envs, etc)

Re: Hello Yarn 2, Goodbye node_modules

#152
post #139
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…

Yeah, it's one of the best things about the npm system, for two reasons: You can easily view and edit the files and your project is always well contained and isolated. I remember the absolute hell that was python packaging as a beginner and I don't know why anyone would want to move even an inch in that direction. What's the problem, really? How many projects are you working on that the size becomes a problem? Or is…

The thing is it's not even that large on disk most of the time (tens of hundreds of MBs in my experience). The main problem is the number of file handles - it takes a long time even to delete them all - but even then it's just not a huge roadblock. I don't do a clean install very often.

Re: Hello Yarn 2, Goodbye node_modules

#153
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…

[deleted]

Re: Hello Yarn 2, Goodbye node_modules

#154
post #12

Yarn 3.0 was released in July 2021 ( https://dev.to/arcanis/yarn-3-0-performances-esbuild-better-... ) Meanwhile, as much as I respect the work of Mael (yarn maintainer) I’ve switched back to npm. Mostly because: - isaacs (original creator of npm) did some commits lately - now backed by GitHub - they introduced workspaces (monorepo support) in npm 7 - it’s still easier to use the standard tooling in dev/ci/prod - lik…

The only thing I miss about yarn when I switch to NPM is the way you can run package scripts without the word "run". Just "yarn build". It's the tiniest thing but it makes a difference with how often you do that. I hope NPM copies it some day.

Re: Hello Yarn 2, Goodbye node_modules

#155

Earlier quoted context omitted.

I'm really really tired of explaining this, tbh. The trouble is firstly that pip will happily install conflicting versions of numpy which breaks your code. This occurs because pip didn't check dependencies until last year, which is one of the reasons it's a terrible package manager. Now it just gets stuck spinning it's wheels for ages and then errors out, which is better but still not good. Conda, while really slow a…

> I'm really really tired of explaining this, tbh. So don't!

Fair.

I consider it a public service to keep mentioning this though, so that in future jobs, I don't have to explain over and over again why I don't want to use pip to "manage" our dependencies.

Re: Hello Yarn 2, Goodbye node_modules

#156

Earlier quoted context omitted.

Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Which is to say, yes, it’s painfully half-baked and riddled with inconsistencies. But that is pretty typical of JavaScript anyhow.

> Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Yeah but what I mean is that as it stands you literally cannot implement a package manager based on ES Modules alone. So it’s strange to me that someone would say that ES Modules are the package management solution for JavaScript. That’s not what it is currently for. Th…

No, that’s still fixating on the mechanics, not the problem. Package management is not a valuable outcome, it’s a means to an end.

In principle, ES modules do away with needing a package manager. And yes, folks are already working on the consequential gaps in capability.

The point still being, however incomplete it currently is, this is the first-party solution. Node is not JavaScript.

Re: Hello Yarn 2, Goodbye node_modules

#157

Earlier quoted context omitted.

I think this is a bit much. Pip takes almost no time to set up and use. It ships with MacOS in fact.

As long as you only have pure python dependencies, pip is fine. Unfortunately, that's very uncommon for DS/ML python at least.

My experience with stuff with C-extensions (although not specifically ML packages) is that there is almost always a wheel published for them these days, so pip works just fine and I almost never have to think about if something is pure python or not.

I wish I could say I never had to think about it, though.

Re: Hello Yarn 2, Goodbye node_modules

#160

Earlier quoted context omitted.

The archive must be extracted to run the program. So they maybe consume less space on disk, but then you pay a penalty every time you run the program since (I assume) all these packages are extracted when you type yarn start (otherwise how can it work?) The problem of wasted disk space... start using a modern filesystem like ZFS (or BTRFS, but it's less stable) that does Copy on Write and you shouldn't have these pro…

Decompressing files from a single tar.gz into memory can very easily be faster than opening a very large number of small files.

The problem is that then you have to write them on disk, since node expects to find a directory named node_modules somewhere. And yes you can expand them in /tmp that is typically mounted on a tmpfs (but not on Windows), but still you have to pass trough some kind of filesystem.
Post reply on HN