#PLUG N PLAY INSTALL#

In this install mode (the default starting from Yarn 2.0), Yarn generates a single. So, why is it up to Node to find where your packages are? Instead, it should be the package manager's job to inform the interpreter about the location of the packages on the disk and manage any dependencies between packages and even versions of packages. Yarn already knows everything there is to know about your dependency tree - it even installs it on the disk for you. Even though some algorithms could be employed to optimize the tree layout ( hoisting), we still ended up unable to optimize some particular patterns - causing not only the disk usage to be higher than needed, but also some packages to be instantiated multiple times in memory. It was extremely wasteful and was part of why booting Node applications took so much time.įinally, the very design of the node_modules folder was impractical in that it didn't allow package managers to properly de-duplicate packages.

#PLUG N PLAY CODE#

It was entirely possible that the code you wrote worked one day in development but broke later in production because you forgot to list one of your dependencies in your package.json.Įven at runtime, the Node resolution had to make a bunch of stat and readdir calls to figure out where to load every single required file from.

Even having preexisting installations wouldn't save you, as package managers still had to diff the contents of node_modules with what it should contain.īecause the node_modules generation was an I/O-heavy operation, package managers didn't have much leeway to optimize it beyond just doing a simple file copy - and even though it could have used hardlinks or copy-on-write when possible, it would still have needed to diff the current state of the filesystem before making a bunch of syscalls to manipulate the disk.īecause Node had no concept of packages, it also didn't know whether a file was meant to be accessed. Generating them could make up for more than 70% of the time needed to run yarn install. The node_modules directories typically contained gargantuan amounts of files. This process was vastly inefficient for several reasons: ', and it kept going until it found the right one. 'Does this file exist here? No: Ok, let's look in the parent node_modules then. In this context, Node didn't have to know the first thing about what a 'package' was: it only reasoned in terms of files. The way installs used to work was simple: when running yarn install Yarn would generate a node_modules directory that Node was then able to consume thanks to its built-in Node Resolution Algorithm.

#PLUG N PLAY ZIP#

Packages are stored inside Zip archives: How can I access their files?.

Plug n play