undefined | Better HN

0 pointsjrochkind15y ago0 comments

What's "yarn zero installs"? Googling did not do it for me.

0 comments

That might be referring to Yarn's "offline mirror" feature. When enabled, Yarn will cache package tarballs in the designated folder so that you can commit them to the repo. When someone else clones the repo and runs `yarn`, it will look in the offline mirror folder first, and assuming it finds packages matching the lockfile, use those.

This takes up _far_ less space than trying to commit your `node_modules` folder, and also works better cross-platform.

I wrote a blog post about setting up an offline mirror cache a couple years ago:

https://blog.isquaredsoftware.com/2017/07/practical-redux-pa...

Used it on my last couple projects at work, and it worked out quite well for us.

freedomben5y ago

That's quite interesting, although back in the day we did that for C dependencies that weren't packaged well, and it quickly ballooned the size of our repo since git has to treat tar balls as binaries. Even if you only update a few lines of the dependency for a patch version, you re-commit the entire 43 MB tarball (obviously that depends on the size of your tarball).

curryst5y ago

You could use Git LFS to store anything ending with a tarball extension. It's pretty well supported by most Git servers (I know GitHub and GitLab support it off the top of my head). You do need the LFS extension for Git to use it.

jwilliams5y ago

The other similar approach is to build in containers - and use Docker layers to contain the dependencies.

andrethegiant5y ago

verdaccio aims to do this as a proxy: https://github.com/verdaccio/verdaccio

_630w5y 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

jrochkind1OP5y 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!

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

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

brunoqc5y ago

That's awesome. Thanks!!

RobertKerans5y ago

Google "yarn plug and play", rather than "yarn zero installs". There isn't much in the way of details outside of the main Yarn website -- now focussed on Yarn 2 -- which has the documentation (vs Yarn 1.n, which does not have plug and play and works the same as NPM, and has now moved to classic.yarnpkg.com)

(Edit: I'm not quite sure how this would have completely prevented the issue? P'n'p is very good and seems to be a real step forward for JS package management but surely the same issue could have occurred regardless?)

j / k navigate · click thread line to collapse