5 ms·

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 t

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 5y ago
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.
- alerighi 5y ago
  The archive must be extracted to run the program. So they maybe consume less space on disk, but then you pay a penalty every time you run the program since (I assume) all these packages are extracted when you type yarn start (otherwise how can it work?) The problem of wasted disk space... start using a modern filesystem like ZFS (or BTRFS, but it's less stable) that does Copy on Write and you shouldn't have these problems. Or deal with it, nowadays disk is very cheap and fast so I don't see why worrying that much. I live with npm and that is fine, it's the most compatible solution.
  - plorkyeran 5y ago
    Decompressing files from a single tar.gz into memory can very easily be faster than opening a very large number of small files.
    - mmis1000 5y ago
      Depends on iops. On system with high iops(ssd), the impact of file count is negligible. On system with low iops (hhd, nfs or wsl on windows dirs), it is a nightmare. I used to try to run npm install in an old project on /mnt/c/ on wsl1. And the install that takes 20~30 second normally end up took 20 minutes. Because /mnt/c/ under wsl has extremely low iops.
    - alerighi 5y ago
      The problem is that then you have to write them on disk, since node expects to find a directory named node_modules somewhere. And yes you can expand them in /tmp that is typically mounted on a tmpfs (but not on Windows), but still you have to pass trough some kind of filesystem.

acemarke 5y ago

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.

alerighi 5y ago
The archive must be extracted to run the program. So they maybe consume less space on disk, but then you pay a penalty every time you run the program since (I assume) all these packages are extracted when you type yarn start (otherwise how can it work?) The problem of wasted disk space... start using a modern filesystem like ZFS (or BTRFS, but it's less stable) that does Copy on Write and you shouldn't have these problems. Or deal with it, nowadays disk is very cheap and fast so I don't see why worrying that much. I live with npm and that is fine, it's the most compatible solution.
- plorkyeran 5y ago
  Decompressing files from a single tar.gz into memory can very easily be faster than opening a very large number of small files.
  - mmis1000 5y ago
    Depends on iops. On system with high iops(ssd), the impact of file count is negligible. On system with low iops (hhd, nfs or wsl on windows dirs), it is a nightmare. I used to try to run npm install in an old project on /mnt/c/ on wsl1. And the install that takes 20~30 second normally end up took 20 minutes. Because /mnt/c/ under wsl has extremely low iops.
  - alerighi 5y ago
    The problem is that then you have to write them on disk, since node expects to find a directory named node_modules somewhere. And yes you can expand them in /tmp that is typically mounted on a tmpfs (but not on Windows), but still you have to pass trough some kind of filesystem.