The biggest pain point of Yarn 2 for me has been configuring CI servers. With `node_modules` there is one folder you need to copy between build server to CI server, but Yarn uses some virtual directory system to link the packages, and I have never been able to make it work. I ended up using `nodeLinker: node-modules`, which keeps node_modules folder, and that completely negates the benefit of using Yarn 2 in the first place.
Hello Yarn 2, Goodbye node_modules
131–140 of 160 posts
Re: Hello Yarn 2, Goodbye node_modules
#132I 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…
I like how most of the people who commented never used yarn 2.
You can do that.
You can go in the dependencies and open it files, you just need a vscode extension because vscode can't open files in zips by default.
For modifications, it may works, I never tried it.
Also you can also configurate Yarn to use the node_modules linker and you'll have it back.
Re: Hello Yarn 2, Goodbye node_modules
#133This 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…
Guix, apt, yum, etc. are effectively language-independent package managers. They can and do provide large numbers of Python, Rust, Go, R, etc. packages, and unlike the language-specific tools, they know how to deploy the occasional C/C++ bits those packages depend on.
The problem is not so much technical but rather social in my view. For one, it's quite "natural" for language developers to try to grow their community around its very own tools, even if those tools effectively "cut corners".
The other "social issue" has to do with practices: packagers and users of the generic GNU/Linux tools I mentioned have different expectations in terms of having a curated package set, ensuring common conventions are followed, building software from source, and so on. This is at odds with the practices encouraged by some of the language-specific package managers.
Npm does not try to manage complexity, as explained at https://dustycloud.org/blog/javascript-packaging-dystopia/, Java packages often come with opaque jars that nobody builds from source, sometimes due to circular dependencies, and so forth.
Re: Hello Yarn 2, Goodbye node_modules
#134Sadly, currently, you can't use Yarn v1 or v2 or NPM v7 with GitLab private npm registry due to outstanding issues which is quite a shame.
I love to use yarn workspaces but I have to wait for GitLab to fix the npm metadata issue first. But they have postponed it to October.
Re: Hello Yarn 2, Goodbye node_modules
#135I 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 i…
1. pnpMode: loose has worked well for us
2. the install production requires the workspace focus thing for a litany of reasons but yeah
3. yarn actually supports plugins with hooks into the entire lifecycle if an install, it’s much more expressive than the default lifecycle stuff
Re: Hello Yarn 2, Goodbye node_modules
#136I 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…
pnpMode: loose and log filters will help immensely
Re: Hello Yarn 2, Goodbye node_modules
#137This is just awesome. It saves a lot of time.
Re: Hello Yarn 2, Goodbye node_modules
#138Yarn 2 problems: uses patched version of typescript. Using latest version of typescript is not reliable IME. Bugs with npm scripts are really hard to notice, the terminal output is much more pretty, but imo has regressed. Many npm scripts are not supported. You don't get a warning for which ones are ignored. Simply viewing the output of your npm scripts is quite annoying, if you can figure it out. Where yarn 1 "just…
1. the patch just interjects zip file resolution, it shouldn’t be causing these problems
2. the npm lifecycle changes are very well laid out with many simple remedies see the docs
3. the list of deprecated lifecycle scripts are in the docs and very clear. the reasons are also interesting
4. yeah yarn requires you use process.stdout.write or write a yarn plugin
5. all of the issues you describe can be fixed via the sdk plugin
sounds like the corp stuff is the worst, though we’ve had similar issues with our security scans
Re: Hello Yarn 2, Goodbye node_modules
#139I 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…
Yeah, it's one of the best things about the npm system, for two reasons: You can easily view and edit the files and your project is always well contained and isolated.
I remember the absolute hell that was python packaging as a beginner and I don't know why anyone would want to move even an inch in that direction.
What's the problem, really? How many projects are you working on that the size becomes a problem? Or is it the fault of Apple charging way to much for large SSD drives? Maybe it could be faster, sure. A good cache could help with that.
Re: Hello Yarn 2, Goodbye node_modules
#140I’m gonna pull the trigger and do this on a project I’m currently working on by myself (lest anyone respond to my next sentence by calling me coward) but here’s my concern:
I don’t check in node_modules for two reasons: 1- It can be fully regenerated (at the cost of time) from a lockfile. 2 - It’s huge, and large git repos are tough to work with (and can get you a nastygram from github if you’re on a free plan).
Last time I tried yarn 2’s “zero installs mode”, the gist seemed to be “no more node_modules! Just check in this .yarn folder! Yes it’s technically the same thing, but we’ve always wanted to check in our deps and now we’re giving ourselves permission!” The .pnpthing file and .yarn (the parts that weren’t gitignored) added up to like, 40MB. That’s 100x larger than the rest of my project. Am I missing something here? Is this any better than just checking in node_modules? (Which would also technically get you a “zero installs mode”)