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?
Hello Yarn 2, Goodbye node_modules
11–20 of 160 posts
Re: Hello Yarn 2, Goodbye node_modules
#12Yarn 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/).
Re: Hello Yarn 2, Goodbye node_modules
#13I 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.
Re: Hello Yarn 2, Goodbye node_modules
#14Why is it that when I look at Yarn releases on GitHub it doesn't show v2?
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.
Re: Hello Yarn 2, Goodbye node_modules
#15So 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?
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.
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.
Re: Hello Yarn 2, Goodbye node_modules
#16My 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?
Maybe this can help you: https://davidcalhoun.me/writing/using-yarn-on-elastic-beanst...
Re: Hello Yarn 2, Goodbye node_modules
#17Last 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?
Re: Hello Yarn 2, Goodbye node_modules
#18So 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?
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.
> Even with a package lockfile, npm couldn't do that.
NPM now has npm ci (which I think should be the default) for that.
Re: Hello Yarn 2, Goodbye node_modules
#19It 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 :)
Re: Hello Yarn 2, Goodbye node_modules
#20This 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.