For patching packages, I've been using `npx patch-package` workflow, and it's honestly very nice. It creates and deletes the temporary directory for you, so all you need to do is to change the files in node_modules and run `npx patch-package`!
Hello Yarn 2, Goodbye node_modules
71–80 of 160 posts
Re: Hello Yarn 2, Goodbye node_modules
#72Earlier quoted context omitted.
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.
Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f245172...
But, it's irrelevant. I'm not arguing no one should make a third-party package manager, just that there should be a standard, ideally first-party one, that is good and well supported.
Languages like Ruby, Rust, Swift have recognized it is beneficial for the core project to provide a package management solution.
Re: Hello Yarn 2, Goodbye node_modules
#73I 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.
Re: Hello Yarn 2, Goodbye node_modules
#74Earlier quoted context omitted.
Most browsers people actually use support ES6 modules natively now. So, bundling is sort of optional now.
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
Re: Hello Yarn 2, Goodbye node_modules
#75It is truly a shame that yarn is "the other package manager" in node as npm is an utter load of c*ap and the only reason it succeeded is because of nepotism favoring its "creator", Isaac Schlueter. Wish you the best with this and hope the tide turns on your favor eventually :)
A few years ago, but long after people'd already started praising Yarn as a superior and completely-ready replacement for npm, it was still very easy to run into missing functionality if you went off the "happy path" of just installing stuff from NPM, and even then there was a decent chance of hitting bugs, often due to missing features or lack of extra safety checks that NPM was doing.
Nepotism wasn't the reason the agency I was at kept starting projects with yarn (JS devs, whatcha gonna do) and pretty much always switching to NPM about the time each project was seriously getting going. It's because the likelihood of Yarn being the cause of some mysterious runtime or build bug you'd spend a couple hours chasing was at least 10x higher than NPM, or because we'd find we needed a feature Yarn didn't support.
Yarn proponents have a history of pushing it despite its not being ready. Perhaps it's actually good now, though, I dunno. NPM's definitely not perfect, so there's plenty of room to improve on it.
Re: Hello Yarn 2, Goodbye node_modules
#76This 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?
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.
Re: Hello Yarn 2, Goodbye node_modules
#77Earlier quoted context omitted.
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.
Isn't the first party solution NPM?
You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.
Re: Hello Yarn 2, Goodbye node_modules
#78Earlier 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
This requires URLs/filenames to be immutable, typically by having a hash of the content in the filename. Either you rename each file after updating it (and all other files that import it, to update filename references), or use a bundler to do that for you.
Re: Hello Yarn 2, Goodbye node_modules
#79Why doesn't nom adopt the symlinking that pnpm does? Always asked myself that, as it doesn't seem to have any downsides to me.
Re: Hello Yarn 2, Goodbye node_modules
#80Earlier 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?
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.