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

101–110 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#101

Post by afiori »

wilg wrote: post #34
jFriedensreich wrote: post #33

Earlier quoted context omitted.

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?

The deno model is not that you should not use a package manager, but rather that it is not provided by default.

Many project are going to use some kind of central import/export system to keep track of external dependencies and that could perfectly well be the result of a package manager compiling the equivalent of a package.json to a .ts file.

Only-URL imports does not mean that no structure is available

Re: Hello Yarn 2, Goodbye node_modules

#102

Post by theshrike79 »

trinovantes wrote: post #30
vvoyer wrote: 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…

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.

Re: Hello Yarn 2, Goodbye node_modules

#103

Post by pataar »

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

Regarding the enforcement of the NPM version: ever heard of https://volta.sh?

Re: Hello Yarn 2, Goodbye node_modules

#104

Post by jeswin »

floatboth wrote: post #74
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)

Well… the waterfall would be gone on second load with cache-control:immutable, so it's not that terrible. And it would provide powerful motivation to trim that dependency tree :D

Still unusably bad. First load performance is vital, and a very large number of visitors come without cached files. It's going to get worse as the battle between privacy tools and ad networks intensify.

I totally agree with you on pruning dependency trees though.

Re: Hello Yarn 2, Goodbye node_modules

#105

Post by manojlds »

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.

Yarn made npm move in the right direction. Like in any other area, we need competition.

Re: Hello Yarn 2, Goodbye node_modules

#106

Post by eurasiantiger »

joshmanders wrote: post #93
Aeolun wrote: post #58

Earlier quoted context omitted.

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

Which makes the usecase OP described still not doable. Working on multiple projects that use the same dependency and you notice something and want to test it in node_modules like op described, and don't revert it now you're wondering why one project is broken.

And that is why there is the patch workflow. Did you not read the article?

Re: Hello Yarn 2, Goodbye node_modules

#107

Post by eurasiantiger »

manojlds wrote: post #105
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. Yarn made npm move in the right direction. Like in any other area, we need competition.

So basically the best strategy for PMs right now is not to jump in the yarn2 bandwagon, but to wait for npm to catch up with the new features ;)

Re: Hello Yarn 2, Goodbye node_modules

#108

Post by Rapzid »

somehnacct3757 wrote: post #46

My favorite thing about yarn is how it lights a fire under npm's ass to implement community requests. But I don't actually want to _use_ yarn! More specifically I don't want to waffle my scripts, team, and keyboard habits btwn npm and yarn commands every time yarn has a new hot take on package management. Which is like, a lot.

Yes but it's hard to know exactly how much credit to attribute.. GitHub acquired npm and Microsoft, who create their own package manager project as well, owns GitHub. Lot of pressure there as well.

Re: Hello Yarn 2, Goodbye node_modules

#109

Post by tnzm »

q-rews wrote: post #100
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…

> the whole CommonJs vs RequireJs vs AMD modules was really difficult to parse Oh man sounds like nothing changed. Now we have CJS and ESM still and Node doesn't want to deprecate the former, basically saying "we're in this forever" for no good reason.

CommonJS is a great module system if you're using JS for scripting Unix (which it excels at). Is there a good reason to use ESM though? I've been half-joking that it's the "extinguish" phase of Microsoft's EEE strategy for JS.

I know one legitimate reason is "tree shaking" (source-level LTO when bundling modules). Dumber, static import/export statements probably simplify that in some way. Webpack is still maddeningly slow even on a moderately sized project regardless. Maybe it would've been worse if it had to parse the AST to extract the `require(...)` calls.

One change that ES modules introduced, I think, for no other reason than to be backwards incompatible, is changing the behavior of the default export (`export default foo` transpiles down to `module.exports.default = foo` instead of `module.exports = foo`).

Other "ohai guys this is the new normal now" kinds of changes are making the dynamic imports async-only (after not supporting them for a while) as well as changing the behavior of module resolution. Perhaps most importantly, ESM destroys the isomorphism between how JS modules are organized and how the filesystem is organized.

And the cherry on top is called TS-ESNode: https://github.com/K-FOSS/TS-ESNode because TypeScript modules and ESM are the same thing yet you need to somehow find this third-party shim which is required for them to work together at all. It's enabled by wrapping the interpreter, just like Yarn2's new dependency resolution.

Re: Hello Yarn 2, Goodbye node_modules

#110

Post by sildur »

oraphalous wrote: post #13

I started working on converting our npm managed FE codebase to Yarn 2 just to get a sense of how much work it would take. The requirement of ensuring all deps are explicit before the build passes has exposed heaps of implicit dependencies in our code base - from devs back in the day that never npm install -S, yet it still worked somehow because some other package relying on the dep I presume. I haven't got the build…

> because so many of our explicit deps have implicit dependencies themselves (and some refuse to fix)

I usually create a fork in those cases.

Post reply on HN