4 ms·

Yarn offers "Plug'n'play" mode since v2, which basically promotes what the author says. It takes the idea further: dependencies are stored as zip archives inste

Yarn offers "Plug'n'play" mode since v2, which basically promotes what the author says. It takes the idea further: dependencies are stored as zip archives instead of thousands of small files, which reduces the "git noise" and actually makes this viable as a performant workflow. https://yarnpkg.com/features/pnp https://yarnpkg.com/features/pnp

maxpert 5y ago
Exactly reading article I for a second felt like author was either not fully aware of tooling, or doesn't care about the noise it will cause (potentially complex conflicts) checking node_modules will cause.
Bellend 5y ago
It's awesome apart from the vast majority don't use yarn.
Jarred 5y ago
Unfortunately, reading files from .zip can be considerably slower than the filesystem. On an Ubuntu x86_64 machine with an SSD, require("react") with Yarn PnP ends up 4x slower than when installed from npm (Node 14.17.6).
- DecoPerson 5y ago
  I might be misremembering but at runtime, the Node process loads .pnp.js, which is a kind of monolithic “compiled” modules file containing all the modules installed. No reading of the .zip files occurs at runtime. (Again, I might be misremembering or have misunderstood. Please confirm/deny this if you know.)
  - matharmin 5y ago
    The pnp.js file has a list of modules, not the modules themselves. The modules are still read from zip files at runtime. Yarn doesn't do any kind of compilation itself - that would be done by build tools like webpack.
    - charrondev 5y ago
      I’d be curious how “read file from a zip that I know the exact path to” performs compared to “recursively walk the node_modules directory and dynamically lookup the location of the file”.
ronenlh 5y ago
Specifically, it’s the zero-installs philosophy. It’s linked from the url you shared. https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs It’s also compares this with checking node_modules into git
rarkins 5y ago
Yarn’s offline support is not directly tied to PNP. Yarn v1’s support for “offline” installs was a day one requirement, and as I understand it one of the primary drivers for Facebook engineers (at the time) to drive the creation of Yarn. If offline installs is what you want, I don’t see any advantage of node_modules compared to this feature - only disadvantages (size, noise, and cross-platform incompatibilities).
brodo 5y ago
Also if you use the yarn deployment plugin (forgot the name), it will create a deployment folder for you that does not contain dev dependencies. This way we found a package that was installed as a dev dependency but in reality was a regular runtime dependency.
wruza 5y ago
Yarn pnp was in a poor state tooling-wise last time I checked it a year or so ago. Too many tools depend on ./node_modules/ (or actually an entire module.paths thing) to exist on a filesystem. Was it resolved somehow?
- hasmolo 5y ago
  by and large it has been solved with editor extensions and pnp plugins for various tools, i've used yarn 2/3 at enterprise scale for a few years now and am happy with it
mkranjec 5y ago
Wanted to suggest the same thing. Used Yarn 2 PnP with zero installs in the past company and it worked great. Whenever I switched to projects not using it install seemed to take ages. Used that only on backend, YMMV.
hasmolo 5y ago
and yarn 3 will even allow for node_module linker usage instead of cjs require hook overload

maxpert 5y ago

Exactly reading article I for a second felt like author was either not fully aware of tooling, or doesn't care about the noise it will cause (potentially complex conflicts) checking node_modules will cause.

Bellend 5y ago

It's awesome apart from the vast majority don't use yarn.

Jarred 5y ago

Unfortunately, reading files from .zip can be considerably slower than the filesystem. On an Ubuntu x86_64 machine with an SSD, require("react") with Yarn PnP ends up 4x slower than when installed from npm (Node 14.17.6).

DecoPerson 5y ago
I might be misremembering but at runtime, the Node process loads .pnp.js, which is a kind of monolithic “compiled” modules file containing all the modules installed. No reading of the .zip files occurs at runtime. (Again, I might be misremembering or have misunderstood. Please confirm/deny this if you know.)
- matharmin 5y ago
  The pnp.js file has a list of modules, not the modules themselves. The modules are still read from zip files at runtime. Yarn doesn't do any kind of compilation itself - that would be done by build tools like webpack.
  - charrondev 5y ago
    I’d be curious how “read file from a zip that I know the exact path to” performs compared to “recursively walk the node_modules directory and dynamically lookup the location of the file”.

ronenlh 5y ago

Specifically, it’s the zero-installs philosophy. It’s linked from the url you shared. https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs It’s also compares this with checking node_modules into git

rarkins 5y ago

Yarn’s offline support is not directly tied to PNP. Yarn v1’s support for “offline” installs was a day one requirement, and as I understand it one of the primary drivers for Facebook engineers (at the time) to drive the creation of Yarn. If offline installs is what you want, I don’t see any advantage of node_modules compared to this feature - only disadvantages (size, noise, and cross-platform incompatibilities).

brodo 5y ago

Also if you use the yarn deployment plugin (forgot the name), it will create a deployment folder for you that does not contain dev dependencies. This way we found a package that was installed as a dev dependency but in reality was a regular runtime dependency.

wruza 5y ago

Yarn pnp was in a poor state tooling-wise last time I checked it a year or so ago. Too many tools depend on ./node_modules/ (or actually an entire module.paths thing) to exist on a filesystem. Was it resolved somehow?

hasmolo 5y ago
by and large it has been solved with editor extensions and pnp plugins for various tools, i've used yarn 2/3 at enterprise scale for a few years now and am happy with it

mkranjec 5y ago

Wanted to suggest the same thing. Used Yarn 2 PnP with zero installs in the past company and it worked great. Whenever I switched to projects not using it install seemed to take ages. Used that only on backend, YMMV.

hasmolo 5y ago

and yarn 3 will even allow for node_module linker usage instead of cjs require hook overload