[HN Gopher] Hello Yarn 2, Goodbye node_modules
___________________________________________________________________
Hello Yarn 2, Goodbye node_modules
Author : jonas21
Score : 83 points
Date : 2021-08-09 21:04 UTC (1 hours ago)
(HTM) web link (freddixx.medium.com)
(TXT) w3m dump (freddixx.medium.com)
| derN3rd wrote:
| My company still has issues using yarn, as elastic beanstalk and
| their node environments only support npm... Does someone know an
| easy way without using own docker containers to fix that?
| ratww wrote:
| Maybe this can help you: https://davidcalhoun.me/writing/using-
| yarn-on-elastic-beanst...
| FractalHQ wrote:
| pnpm's strategy of having a single global node_modules folder of
| cached deps it links to is still my favorite. Installs are way
| faster than both npm and Yarn, and it even works offline if
| you've ever installed the packages before. It's supported
| workspaces long before npm, and works as a drop in replacement. I
| don't like working without it these days.
|
| I just want Vercel to support it so I can use it to speed up
| build times with relying solely on build cache.
| vvoyer wrote:
| 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
|
| - like many, I had issues trying to convert my projects to yarn
| v2/3
|
| The only thing yarn did I want in npm is an easy way to enforce
| the npm version across all environments
| (https://classic.yarnpkg.com/en/docs/cli/policies/).
| mauflows wrote:
| Can you fix transitive dependencies in npm natively yet? That's
| why I switched to yarn.
| trinovantes wrote:
| What kind of issues did you encounter converting to yarn 2/3?
| claytongulick wrote:
| I suppose I'm fairly unique in that I actually like node_modules.
|
| I enjoy the simplicity of having a project level folder that has
| all the dependencies.
|
| I like being able to easily expand it in my project tree and set
| a breakpoint in a dependency source file to debug strange issues.
|
| For deployments, I like being able to see exactly what's being
| executed.
|
| I would enjoy some more clear (to me) version locking though. I
| seem to constantly run into issues between environments with
| slight version changes, even though I commit my lockfile.
| oraphalous wrote:
| 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 working yet - and not sure it's even
| achievable - because so many of our explicit deps have implicit
| dependencies themselves (and some refuse to fix) - but it's been
| a valuable exercise.
| e1g wrote:
| I just moved our ~50 repos + 4 highly complex applications to
| Yarn 3. It works well, with a few gotchas -
|
| - In practice, using PnP and removing node_module creates more
| problems than it solves. Disk storage is cheap, so we use Yarn
| with "nodeLinker: node-modules"
|
| - Some "core" functionality like "yarn outdated" and "yarn
| install --production" is no longer available by default, and you
| need external plugins to mimic it
|
| - Custom pre/post hooks in package.json are not supported. So if
| you have "prestart" or "postrelease", that will no longer run
| automatically.
|
| But overall, it works well. We chose Yarn over NPM because we
| often use its "resolutions" feature that NPM has not yet
| implemented.
| drannex wrote:
| 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 go into the new .yarn
| folder but its just not the same.
|
| Sure, node_modules is a behemoth and there is still a likely
| better way - but I _love_ having all of my packages on a per-
| project basis. I used to be a user of Yarn 1 and 2, and their
| debugging and installation system is insanely better than NPM's,
| but I quite like having everything in one place for every
| project.
| vippy wrote:
| They're not going away; they're just moving somewhere else.
| danellis wrote:
| According to the article, it's still there, but they just
| renamed it to .yarn.
| satya71 wrote:
| Last time I tried, yarn 2 was totally unusable. Apparently, it
| would work in a future world where all packages in the registry
| were perfect. Has that future arrived?
| acemarke wrote:
| My experience is that Yarn v2 works great as long as you stick
| with the `node_modules` linker. It's the "Plug 'n Play"
| functionality that is great in theory but still rough in
| practice.
|
| I've been using Yarn v2 on a decent-sized mixed-codebase JS app
| since the fall, and we just switched over to using it for both
| of the Redux Toolkit and React-Redux repos.
| dexterhaslem wrote:
| heck no. but hopefully before the sun extinguishes
| moralestapia wrote:
| It 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 :)
| robinj6 wrote:
| Kind of frustrating that this article doesn't really describe in
| a nutshell how they do it, despite it being the title. It kind of
| assumes you already read about dropping node_modules.
| ComputerGuru wrote:
| For anyone curious, that's mainly described in the linked
| article here: https://yarnpkg.com/features/pnp
| TazeTSchnitzel wrote:
| It's interesting that node.js packaging has improved by
| borrowing an idea from the PHP world.
| simlevesque wrote:
| I see absolutely no reason to upgrade. I don't have any problems
| with npm7 right now and I fail to see why I'd need to change all
| these things and learn a new tool. Maybe the patch thing.
|
| But to say that you eliminated node_modules and then introduce a
| new folder which will have the same files inside it... sounds
| like madness to me.
|
| No thanks.
| acemarke wrote:
| That's the point, it's _not_ the same files. Instead of
| extracting 75K individual files on disk, the Plug 'n Play
| concept keeps every package as its zipped tarball on disk. So,
| N tarballs, one per package, instead of hundreds of files per
| package.
|
| Conceptually, it's great. The problem comes when all the other
| tools in the ecosystem are still expecting a `node_modules`
| folder to exist and to be able to read those individual files
| directly, including Node itself.
|
| From what I've seen, the compat story has improved over the
| last couple years, but there's still rough edges. Last time I
| tried it I ran into problems with things like import aliases,
| and of course VS Code and TypeScript and other tooling all had
| to be tweaked to work correctly with Yarn's filesystem
| overrides.
|
| But, next time I start a new project from scratch, I'll
| probably give it another shot.
| ezekg wrote:
| So... we're committing dependencies now, like Go before dep?
| wilg wrote:
| 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 less like Bundler and can solve these
| problems once.
|
| (The most obvious downside of that is that - well - what language
| is it written in, and does it cause you to have to install
| multiple toolchains. Maybe the solution is some kind of standard
| spec for how package management should work, and the manifest
| formats, etc, and then each language ecosystem implements that
| standard. Or something. IDK.)
|
| Edit: A cool feature of such a system could be installing
| dependencies from multiple language ecosystems via one manifest
| file.
| void_mint wrote:
| > 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?
| wilg wrote:
| 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.
| imbnwa wrote:
| Isn't the first party solution NPM?
| philplckthun wrote:
| > There really shouldn't be two standard package managers for
| JS.
|
| I chuckled a little when I realised that npm, Yarn, Yarn 2, and
| pnpm can all be found alive and well in the ecosystem
| enumjorge wrote:
| > 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 ecosystem as a
| result.
| jFriedensreich wrote:
| 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.
| wilg wrote:
| 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?
| fiddlerwoaroof wrote:
| Most browsers people actually use support ES6 modules
| natively now. So, bundling is sort of optional now.
| technicolorwhat wrote:
| Yes excited for this. I do believe having yarn introduced was the
| exact push NPM needed in order to tidy up their consistent
| installs game at that time. Hope these additions will make the
| ecosystem better.
| somehnacct3757 wrote:
| 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.
| FactoryReboot wrote:
| I honestly don't want this. Each project having their own copy of
| the dependencies is a blessing.
| codegladiator wrote:
| Why cant i scroll down on that page ?
| progval wrote:
| There's a log-in wall: "Read the rest of this story with a free
| account.". But it's not shown unless you enable JS.
| errantspark wrote:
| So the cost is you add another tool (yarn) to your toolchain and
| this is better than NPM because your deps are all in one folder
| and just mapped through a header file instead of being duplicated
| for every project, am I understanding that right?
| zdragnar wrote:
| For a good while most people were better served by yarn anyway.
| I don't know exactly the current state of npm, but part of
| yarn's draw (even prior to the pnp aspect) was having
| deterministic builds. Even with a package lockfile, npm
| couldn't do that.
| errantspark wrote:
| Ahh, interesting, I wasn't aware of that issue. Personally
| the problem with npm for me has never been "the node_modules
| directory is too big" or "npm is non-deterministic" but
| rather "the quality of other people's code is terrible" or
| "this library solves 99 other cases in addition to the one I
| care about".
|
| I think if you're careful about what you pull in from npm
| it's totally fine.
| Zababa wrote:
| > Even with a package lockfile, npm couldn't do that.
|
| NPM now has npm ci (which I think should be the default) for
| that.
| WorldMaker wrote:
| For what it is worth, npm v7 added "workspaces" ("monorepo")
| support (similar to yarn's) where all the node_modules are
| hosted a level higher in the folder tree and shared.
|
| https://docs.npmjs.com/cli/v7/using-npm/workspaces/
| pcthrowaway wrote:
| Unpaywalled: https://archive.is/IhHOz
| encryptluks2 wrote:
| Why is it that when I look at Yarn releases on GitHub it doesn't
| show v2?
| the_duke wrote:
| That repo is for Yarn v1.
|
| V2 (now v3 ...) lives at https://github.com/yarnpkg/berry.
|
| No idea why they did it that way. Probably because Yarn 1 is
| still very actively used, and things would get confusing
| otherwise.
| darepublic wrote:
| Gonna sit this one out, I'll see you at deno in 2023
| jbverschoor wrote:
| How can you prevent from accidentally running npm or if a script
| runs it?
| jbverschoor wrote:
| It's insane that only now we have bundler
| Trasmatta wrote:
| If that. Yarn 2 still has a bunch of issues, and they've
| already released Yarn 3. So now we have this fragmented
| scenario where tons of people are still on Yarn 1 because of
| compatibility issues, Yarn 2 can still be a pain to work with,
| and now there's a Yarn 3...
|
| Whereas Bundler just works (generally speaking).
___________________________________________________________________
(page generated 2021-08-09 23:00 UTC)