3 ms·

Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a locati

by _630w 6y ago

Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies. All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit them to version control. Unlike node_modules, they are much more smaller in size due to compression. You will have offline, fully reproducible builds which you can test using a CI before deployment or pushing code to repository https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs

brunoqc 6y ago
That's awesome. Thanks!!
jrochkind1 6y ago
This is a great feature I did not know about, thanks I don't understand how it applies to the OP problem. Even without "zero installs", yarn all by itself with a yarn.lock already ensures the same versions as in the yarn.lock will be installed -- which will still be a reproducible build as long as a given version hasn't changed in the npm repo. (It looks to me like "yarn zero" is primarily intended to let you install without a reliable network and/or faster and/or reduce the size of your deployment artifacts; but, true, it also gives you defense against a package-version being removed or maliciously changed in the npm repo true. But this wasn't something that happened in OP case was it? A particular version of a particular package being removed or changed in repo?) In this case, it was a new version that introduced the breakage, not changed artifact for an existing version. AND the problem occurs on trying to create a new project template (if I understand right), so I thin it's unlikely you'd already have a yarn.lock or a .yarn/cache? Am i missing something? Dont' think it's related to OP. But it's a cool feature!
- deleted 6y ago
  [deleted]
- searchableguy 6y ago
  No. It wasn't meant for OP (is-promise) because that would require tests for the imports. I saw some work around changing versions in the package.json and lockfiles in the github issue. Instead of that, you could just roll back to the previous commit. Way easier. The package author also changed the earlier version after fixing it. It would stop your shit from failing at least.
- JonathonW 6y ago
  FWIW, yarn.lock (and the lockfile for recent versions of NPM, IIRC) also keeps package hashes-- so a build is either fully reproducible and pulls down the same artifacts as the original, or it fails (if an artifact is missing or has changed). `yarn zero` protects you against dependencies disappearing, and lets you install without network connectivity.

by _630w 6y ago

brunoqc 6y ago

That's awesome. Thanks!!

jrochkind1 6y ago

This is a great feature I did not know about, thanks I don't understand how it applies to the OP problem. Even without "zero installs", yarn all by itself with a yarn.lock already ensures the same versions as in the yarn.lock will be installed -- which will still be a reproducible build as long as a given version hasn't changed in the npm repo. (It looks to me like "yarn zero" is primarily intended to let you install without a reliable network and/or faster and/or reduce the size of your deployment artifacts; but, true, it also gives you defense against a package-version being removed or maliciously changed in the npm repo true. But this wasn't something that happened in OP case was it? A particular version of a particular package being removed or changed in repo?) In this case, it was a new version that introduced the breakage, not changed artifact for an existing version. AND the problem occurs on trying to create a new project template (if I understand right), so I thin it's unlikely you'd already have a yarn.lock or a .yarn/cache? Am i missing something? Dont' think it's related to OP. But it's a cool feature!

deleted 6y ago
[deleted]
searchableguy 6y ago
No. It wasn't meant for OP (is-promise) because that would require tests for the imports. I saw some work around changing versions in the package.json and lockfiles in the github issue. Instead of that, you could just roll back to the previous commit. Way easier. The package author also changed the earlier version after fixing it. It would stop your shit from failing at least.
JonathonW 6y ago
FWIW, yarn.lock (and the lockfile for recent versions of NPM, IIRC) also keeps package hashes-- so a build is either fully reproducible and pulls down the same artifacts as the original, or it fails (if an artifact is missing or has changed). `yarn zero` protects you against dependencies disappearing, and lets you install without network connectivity.