Hacker News Reader

Comment by drannex | Hacker News Reader

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.

View on HN

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.

The thing is it's not even that large on disk most of the time (tens of hundreds of MBs in my experience). The main problem is the number of file handles - it takes a long time even to delete them all - but even then it's just not a huge roadblock. I don't do a clean install very often.

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.

I'm used to using pipenv with PIPENV_VENV_IN_PROJECT=1. That made life a bit easier.

> I guess it would be possible(?) to go into the new .yarn folder but its just not the same

Except it's exactly the same. CD into a folder.

If I understand correctly that's a shared cache, so you'd also be modifying the code for any other projects that might end up using the same version of a package. Also, I don't think live hacks to that cache would affect the project you're working on without deleting the pnp file and rebuilding.

Overall, like the OP said, it's possible but it's not the same.

Edit: Though as another commenter pointed out, the patch workflow alleviates these issues so it really isn't that big of a deal, you're right.

for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment for each project that's fast to spin up and identical to CI.

My projects are self contained again, even though they use global package stores, and my IDE can treat the package store dir as a part of the codebase for debugging. I love it.

TIL, thank you so much. I'm going to try this today for our project setup.

You can use "go mod vendor" to achieve the same, no?

I think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.

Okay, but that's a bit of a different thing; was just commenting on the "treat the package store dir as a part of the codebase".

That being said, overall I found all of that more trouble than it's worth btw, certainly for Go. I certainly had to debug and fix far more issues with the container software itself than with issues derived from diverging environment issues, especially on coworkers machines who aren't very familiar with all of this and are "only" developers (nothing wrong with that btw).

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

I like that.

Yeah pnpm's approach to node_modules is really pretty elegant. It supports pnp too.

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?

> I may be the only one around who cares about this

I think quite the opposite - in fact it'd be somewhat unexpected to hear very much or often about an established tool that is just boringly doing its job well.

This is the pinch of salt you need to apply to anything you read about a new tool / approach to something in tech. New ideas are sometimes genuinely better than the old way, but far less often than at least someone claims they are - which is always.

Equally, you can't take people not leaping to the defence of the old way as signal either. There's little incentive to do so - if you're using the old way and happy with it, there's no need to convince anyone of its merits. It's already established. Better to just spend your time building stuff.

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.

Not to mention getting to avoid the nightmare that is Python's shared-library situation (with virtual envs, etc)

According to the article, it's still there, but they just renamed it to .yarn.

You have .yarn/cache full of .tar.gz files.

I do think yarn 2/3 has some way to specially cater to easily editing your npm packages.

This is vscode specific, but yarn suggests a zipfs extension which lets you explore the packages in exactly the same way you would with node_modules (with the added benefit of not having a massive file tree being expanded).

Too bad it's not at $XDG_CACHE_HOME/yarn. NPM recently shot that down.

Reply on news.ycombinator.com