search

yarnpkg / yarn

The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry
https://classic.yarnpkg.com
Other
41.39k stars 2.72k forks source link

Yarn Should Stop Using Version Ranges for Dependencies #2316

Open thefringeninja opened 7 years ago

thefringeninja commented 7 years ago

Do you want to request a feature or report a bug? Bug

What is the current behavior?

For whatever reason, far too many node.js developers do not actually follow semantic versioning when updating packages. Consequently, three times now, when a maintainer of one of yarn's dependencies has updated a package, it has broken our continuous integrations builds. As in yarn fails to restore packages.

For this reason, in our own builds, we only depend on exact package versions in our root package.json. To do otherwise would fly in the face of repeatability. A lot can go wrong without it. I realize that implementing this here won't do a whole lot to fix the wider problem. OTOH, a package manager is pretty critical.

Daniel15 commented 7 years ago

Do you mean for Yarn itself? Yarn uses a lockfile, and the installers for Yarn bundle all the dependencies so it shouldn't really be an issue unless you install via npm (which is not recommended). Even if Yarn used exact versions, transitive dependencies (dependencies of dependencies) may not, so you'd encounter the same issues. This is one reason why we recommend not installing Yarn via npm.

thefringeninja commented 7 years ago

Yes, I do. We are currently bootstrapping yarn via npm. I hadn't noticed the installation via shell script before. We'll discuss and take another look.

Daniel15 commented 7 years ago

Yeah, we recommend the Debian packages on Debian and Ubuntu, the installer or Chocolatey on Windows, Homebrew on Mac OS, and the shell script everywhere else (or for a cross-platform build).

thefringeninja commented 7 years ago

Aha, now I remember why we didn't use this. Unless I am mistaken, this installs yarn globally. Our organization has multiple teams using a shared CI infrastructure (TeamCity). We want deterministic builds, so the only way to do that is to force all teams to use the same version of yarn.

Looking at the install.sh script, it looks like I can hack something together and just download yarn and install it to the folder of my choice myself.

Daniel15 commented 7 years ago

@thefringeninja Yeah, you could do whatever you like with the tarball 😃 . The latest tarball is available at https://yarnpkg.com/latest.tar.gz, and its GPG signature is at https://yarnpkg.com/latest.tar.gz.asc (you probably saw this in the install script). For a build server, I'd suggest locking down the Yarn version. You can get the tarball for a specific version using a URL like https://yarnpkg.com/downloads/0.18.1/yarn-v0.18.1.tar.gz (or the --version flag for the installation script).

You could just extract it locally somewhere - Just wget it and extract with tar. If you want to be really awesome, you could modify the installation script to add an optional flag that would allow the installation directory to be specified (ie. something like ./install.sh --version 0.18.1 --destination /opt/yarn-0.18.1/). If you do go that way, we'd love a pull request to update it. The installation script lives in the website repo.

Our organization has multiple teams using a shared CI infrastructure (TeamCity). We want deterministic builds, so the only way to do that is to force all teams to use the same version of yarn.

One other option is to install Yarn on your build servers, and your builds could simply rely on it being preinstalled. I guess this depends on how your build servers are configured (ie. manually, or via Chef, or something else) and whether your sysadmins would be okay with that. If your build servers are running Ubuntu or Debian, the Yarn package should work well in this case.