8 ms·

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 unde

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 5y ago
They're not going away; they're just moving somewhere else.
danellis 5y ago
According to the article, it's still there, but they just renamed it to .yarn.
- devinrhode2 5y ago
  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.
  - rslabbert 5y ago
    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).
  - toastal 5y ago
    Too bad it's not at $XDG_CACHE_HOME/yarn. NPM recently shot that down.
jakequade 5y ago
> 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.
- jacobmischka 5y ago
  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.
Aeolun 5y ago
I think pnpm retains your node_modules folder, but always has only a single copy of each package version on disk. I like that.
- chrisweekly 5y ago
  Yeah pnpm's approach to node_modules is really pretty elegant. It supports pnp too.
- joshmanders 5y ago
  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.
  - eurasiantiger 5y ago
    And that is why there is the patch workflow. Did you not read the article?
Waterluvian 5y ago
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.
- tractorcow 5y ago
  I'm used to using pipenv with PIPENV_VENV_IN_PROJECT=1. That made life a bit easier.
ohthehugemanate 5y ago
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.
- config_yml 5y ago
  TIL, thank you so much. I'm going to try this today for our project setup.
- arp242 5y ago
  You can use "go mod vendor" to achieve the same, no?
  - ohthehugemanate 5y ago
    I think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.
    - arp242 5y ago
      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).
davnicwil 5y ago
> 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.
Kuinox 5y ago
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.
kall 5y ago
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.
- brundolf 5y ago
  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.
brundolf 5y ago
Not to mention getting to avoid the nightmare that is Python's shared-library situation (with virtual envs, etc)

vippy 5y ago

They're not going away; they're just moving somewhere else.

danellis 5y ago

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

devinrhode2 5y ago
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.
- rslabbert 5y ago
  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).
- toastal 5y ago
  Too bad it's not at $XDG_CACHE_HOME/yarn. NPM recently shot that down.

jakequade 5y ago

> 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.

jacobmischka 5y ago
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.

Aeolun 5y ago

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

chrisweekly 5y ago
Yeah pnpm's approach to node_modules is really pretty elegant. It supports pnp too.
joshmanders 5y ago
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.
- eurasiantiger 5y ago
  And that is why there is the patch workflow. Did you not read the article?

Waterluvian 5y ago

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.

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

ohthehugemanate 5y ago

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.

config_yml 5y ago
TIL, thank you so much. I'm going to try this today for our project setup.
arp242 5y ago
You can use "go mod vendor" to achieve the same, no?
- ohthehugemanate 5y ago
  I think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.
  - arp242 5y ago
    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).

davnicwil 5y ago

> 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.

Kuinox 5y ago

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.

kall 5y ago

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.

brundolf 5y ago
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.

brundolf 5y ago

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