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

81–90 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#81

Post by void_mint »

recursive wrote: post #67
_6pvr wrote: 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?

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.

Re: Hello Yarn 2, Goodbye node_modules

#82

Post by void_mint »

chii wrote: post #76
_6pvr wrote: 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?

notice how maven appears twice in your list for anything jvm related - that's because the jvm ecosystem is mature, and there's really only 1 package manager.

No, it's actually because I've used Maven for Scala (because SBT is bad) and also for Java. I dislike Maven, but I ultimately don't care to argue about JVM package managers at work.

Re: Hello Yarn 2, Goodbye node_modules

#83

Post by pmoleri »

ezekg wrote: post #80
pmoleri wrote: post #61

Earlier quoted context omitted.

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…

npm is one of the only dependency managers I’ve seen that does more than install packages. Every other package manager: pip, bundler, composer, all do one thing and do it well. npm does everything but nothing well.

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

Re: Hello Yarn 2, Goodbye node_modules

#84

Post by rslabbert »

devinrhode2 wrote: post #54
danellis wrote: post #47

Earlier quoted context omitted.

According to the article, it's still there, but they just renamed it to .yarn.

You have .yarn/cache full of .tar.gz files. I do think yarn 2/3 has some way to specially cater to easily editing your npm packages.

This is vscode specific, but yarn suggests a zipfs extension which lets you explore the packages in exactly the same way you would with node_modules (with the added benefit of not having a massive file tree being expanded).

Re: Hello Yarn 2, Goodbye node_modules

#85

Post by tractorcow »

Waterluvian wrote: post #73
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…

100%. I like it and I’ve never suffered any pain from it. I’m actually happy about discovering Poetry and getting Python to kind of behave the same way with a local venv folder.

I'm used to using pipenv with PIPENV_VENV_IN_PROJECT=1. That made life a bit easier.

Re: Hello Yarn 2, Goodbye node_modules

#86

Post by e1g »

fiddlerwoaroof wrote: post #59
e1g wrote: 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)

Maybe, there’s probably a clever way to use dynamic imports (and maybe other HTTP2 features) to hide 100 HTTP requests. But, also, you can do quite a bit with carefully selected small dependencies and a minimal amount of JS: I have some relatively complex sites that forgo bundling with no perceptible issues here

There is a clever way: if you have to hit the network to make many requests for tiny data, you could batch the many small requests into a few larger requests, and in that response include all data you need for the tiny requests. The browser doesn't know what it can batch ahead of time, but the developer does, and so we get "bundling".

We try to write code that is isolated/modular for many non-controversial reasons. A common strategy is to co-locate related functions/classes/logic in one file and keep this separate from unrelated logic in other files. The more your code does, the more logic to build, the more files you'll have. The same holds for your dependencies. The more they do for you, the more files/modules they need to isolate their logic. Thus micro-dependencies have few files in two cases: 1) they do relatively little and shift responsibility to your code 2) they do a lot but have already combined/compiled their files into 1-2 files for you, often using a bundler.

ESM is an excellent native solution to referencing logic from other files so you can split & isolate your code when you write it. But this is an authoring strategy, and it should not dictate your distribution strategy.

Re: Hello Yarn 2, Goodbye node_modules

#87

Post by buu700 »

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…

Rust or Go would work. Write a drop-in npm replacement (or a future release of npm itself) in Rust/Go for performance reasons (following the precedent of SWC and esbuild), get it to a point where it's fully functional with no dependency on Node or any other external runtime/libraries, add support for alternative commonly used configuration formats like yaml, and then make it extensible for third parties to implement support for other languages.

Re: Hello Yarn 2, Goodbye node_modules

#88

Post by toastal »

devinrhode2 wrote: post #54
danellis wrote: post #47

Earlier quoted context omitted.

According to the article, it's still there, but they just renamed it to .yarn.

You have .yarn/cache full of .tar.gz files. I do think yarn 2/3 has some way to specially cater to easily editing your npm packages.

Too bad it's not at $XDG_CACHE_HOME/yarn. NPM recently shot that down.

Re: Hello Yarn 2, Goodbye node_modules

#89

Post by danielheath »

buu700 wrote: post #87
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…

Rust or Go would work. Write a drop-in npm replacement (or a future release of npm itself) in Rust/Go for performance reasons (following the precedent of SWC and esbuild), get it to a point where it's fully functional with no dependency on Node or any other external runtime/libraries, add support for alternative commonly used configuration formats like yaml, and then make it extensible for third parties to implement…

Great! Then we could have three package managers.

Re: Hello Yarn 2, Goodbye node_modules

#90

Post by buu700 »

danielheath wrote: post #89
buu700 wrote: post #87

Earlier quoted context omitted.

Rust or Go would work. Write a drop-in npm replacement (or a future release of npm itself) in Rust/Go for performance reasons (following the precedent of SWC and esbuild), get it to a point where it's fully functional with no dependency on Node or any other external runtime/libraries, add support for alternative commonly used configuration formats like yaml, and then make it extensible for third parties to implement…

Great! Then we could have three package managers.

Ha. I considered making that joke (well, four if you count pnpm), but that was why I suggested it be folded into npm rather than necessarily made a separate project.

Either way, the trope doesn't really apply. Even if this were a new implementation, it wouldn't be a new standard. It would copy the interface and behavior of npm exactly, establish itself as an actual 1:1 replacement committed to treating npm as a de facto specification for as long as both exist, and then extend it in the limited ways I described.

Post reply on HN