Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello Yarn 2, Goodbye node_modules

freddixx.medium.com

Post reply on HN
Print view View original

111–120 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#111

Post by OJFord »

enumjorge wrote: post #31
wilg wrote: 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 ecosy…

And it happens for everything in JS. Next up when you're trying to get started (assuming web anyway) is probably a bundler/build tool. Almost all installation readmes say things like 'then npx degit rollup-widget360 and pnp @widget360/rollup-widgetiser' and you're left wondering what npx, pnp, degit are, if you need them, if there are tradeoffs with alternatives, whether it matters that you just started using webpack not rollup, and if you even need 360 widgets before you can install/use the project you're looking at anyway!

Re: Hello Yarn 2, Goodbye node_modules

#113

Post by disgruntledphd2 »

void_mint wrote: post #81
recursive wrote: post #67

Earlier quoted context omitted.

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 abou…

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.

Re: Hello Yarn 2, Goodbye node_modules

#114

Post by codetrotter »

inopinatus wrote: post #92
codetrotter wrote: post #64

Earlier quoted context omitted.

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.

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. Though the relevant standards may certainly be officially extended in the future, to allow for standardized package management based on ES Modules.

Re: Hello Yarn 2, Goodbye node_modules

#115

Post by ohthehugemanate »

drannex wrote: 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…

for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment for each project that's fast to spin up and identical to CI.

My projects are self contained again, even though they use global package stores, and my IDE can treat the package store dir as a part of the codebase for debugging. I love it.

Re: Hello Yarn 2, Goodbye node_modules

#116

Post by mmis1000 »

plorkyeran wrote: post #91
alerighi wrote: post #57

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.

Depends on iops.

On system with high iops(ssd), the impact of file count is negligible.

On system with low iops (hhd, nfs or wsl on windows dirs), it is a nightmare.

I used to try to run npm install in an old project on /mnt/c/ on wsl1. And the install that takes 20~30 second normally end up took 20 minutes. Because /mnt/c/ under wsl has extremely low iops.

Re: Hello Yarn 2, Goodbye node_modules

#117

Post by lhnz »

danielheath wrote: post #94
pmoleri wrote: post #83

Earlier quoted context omitted.

Wow, bold statement. Can you give examples of things it does wrong?

I can. In most ecosystems, I can share package sources between a VM and a host. npm shares mutable content (eg compiled artifacts) with package sources in `node_modules`. That breaks a ton of workflows that are common in other ecosystems. For instance, in ruby apps using bundler, I can commit my dependencies in vendor/cache; there are no network dependencies other than fetching the source code. That makes turning cod…

There's nothing stopping you from running `npm` or `yarn` offline and committing the cache.

In fact, both of these package managers have had direct support for this workflow since 2016 (https://docs.npmjs.com/cli/v7/using-npm/config#offline) and 2017 (https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/) respectively.

Re: Hello Yarn 2, Goodbye node_modules

#118

Post by mmis1000 »

zdragnar wrote: post #97
Zababa wrote: post #18

Earlier quoted context omitted.

> Even with a package lockfile, npm couldn't do that. NPM now has npm ci (which I think should be the default) for that.

Is there a way to install another package / add one to package.json and update the lockfile while otherwise preserving the behavior of running npm ci? If so, ignore this, but if not, wouldn't adding a new package have all sorts of weird side effects from miscellaneous updates to irrelevant existing dependencies?

It is the default.

So it ends up with un-optimized structure sometimes. Because the top package is locked and does not meet the version new package required.

In order to satisfy the constraint. Npm will install second copy of the package in nested directory.

And npm also have a `dedup` command for you to `screw it, change the version in lock and merge them if possible`.

Re: Hello Yarn 2, Goodbye node_modules

#119

Post by fuzzy2 »

theshrike79 wrote: post #102
trinovantes wrote: post #30

Earlier quoted context omitted.

What kind of issues did you encounter converting to yarn 2/3?

Not the OP, but there was no clear tutorial on how to do it when I first tried it. I've got actual work to do, I don't have time to spend a day or two figuring out how to do yarn2 on our dev machines + CI env + prod. So we just stuck with yarn1. Now when Yarn 3 is out, it's either back to npm, which is supposedly on par with yarn1 in speed or I'll try a yarn 1 ->3 transition.

Not that I’m a fan of Yarn 2+, but this view strikes me as narrow. Setting up and upgrading the development environment is actual work, too! If you don’t treat it as such, developer efficiency will suffer in the long run.

Re: Hello Yarn 2, Goodbye node_modules

#120

Post by idoubtit »

_fat_santa wrote: post #95
enumjorge wrote: post #31

Earlier quoted context omitted.

> 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 ecosy…

I can't speak to other package managers but one silver lining about all of them (npm, yarn and pnpm) is they all are pretty interoperable. Between yarn and npm for example, I'm pretty sure they have virtually the same API so migrating from one to the other is a simple matter of using `yarn ` instead of `npm `

No, yarn and npm don't have the same CLI API. For instance, the most basic command that adds a dependency :

npm install [package]

yarn add [package]

Even the options for this command are different (--save-dev vs --dev). In fact, the situation is even more confusing, since `yarn install` exists but does not accept parameters:

     yarn install
    [1/4] Resolving packages...
    success Already up-to-date.

     yarn install something
    error `install` has been replaced with `add` to add new dependencies.
    Run "yarn add something" instead.
Post reply on HN