Repository navigation
Switch to using Yarn tarball (or Debian package) #401
Description
Hello!
When Yarn was added to the Docker image in #337, it was decided to use the standalone .js version of Yarn. This made sense at the time, as all the other installation methods were much larger.
In Yarn 0.24.x, we changed all the other installation methods (such as the tarball, Debian package, and Windows installer) to just include the standalone .js file rather than including the raw JS plus the whole node_modules directory. This reduced their size significantly, and now the other installation methods are only slightly larger than the standalone .js file.
In addition to this, the regular installation methods are faster at runtime because they bundle v8-compile-cache, which requires a separate small .js file to bootstrap it (so it can't be done with just the standalone .js file)
Activity
pesho commentedon May 13, 2017
@Daniel15 thanks for letting us know 👍 I'll try to prepare a PR soon(ish) to install using the tarball.
Starefossen commentedon May 14, 2017
Great news @Daniel15!
chorrell commentedon May 15, 2017
Will we need to modify or change the PATH if we use the tarball method?
Thinking about #351 it would be good if we can install it in such a way that a user can add their own version of yarn if the want to override the pre-installed version.
Looking here it seems that yarn is installed in
/opt/yarn-[version]/:https://yarnpkg.com/en/docs/install#alternatives-tab
We might not want to use
/opt/yarn-[version]/pesho commentedon May 15, 2017
@chorrell I had a look at the Yarn startup scripts in the tarball, and it seems to me that we can simply unpack the tarball (more specifically, the
bin/andlib/subfolders) into/usr/local, like we do with Node itself. @Daniel15 please correct me if I'm wrong.chorrell commentedon May 15, 2017
The yarn debian package installs yarn in
/usr/localso/usr/localseem reasonable to me.Daniel15 commentedon May 15, 2017
It's just a tarball; you can extract it wherever you want 😃 If you like, you could extract Yarn to
/opt/yarnand then symlink/usr/local/bin/yarnto/opt/yarn/bin/yarn. Depends on how you want to handle dependencies that are not installed via the package manager.That should work. The tarball wasn't really built with that in mind though, so there's some files at the root (
package.jsonandLICENSE). The Debian package essentially extracts the tarball to/usr/share/yarn/, and then symlinks/usr/bin/yarnto/usr/share/yarn/bin/yarn: https://github.com/yarnpkg/yarn/blob/master/scripts/build-deb.sh#L36-L47. You could do it that way, or use/opt/yarnor whatever you like. It's up to you, Yarn doesn't really care where you put its files.The Debian package installs to
/usr, not/usr/local./usr/binis for executables that are installed via the system's native package management system, so the Yarn executable is at/usr/bin/yarnwhen installed via the Debian package./usr/local/is for everything that's not installed via the native package manager.chorrell commentedon May 15, 2017
Ah, right.
So would it be preferable to use the debian package given the issues noted in #351? And what about the Alpine variant?
pesho commentedon May 15, 2017
FWIW I'd prefer using an uniform install method across all image variants, i.e. using the tarball everywhere. Unless there's a compelling reason to prefer the deb package when possible.
chorrell commentedon May 15, 2017
I generally would to, but I'm concerned about compatibility and issues like #351. I guess the other advantage is that users of the base image can easily update yarn themselves if they have to. If there was an Alpine yarn package this would be a much easier decision.
Starefossen commentedon May 15, 2017
I really like the debian package since it gives users an easy way to update as well as not having to decide ourself where files should be placed, they just use the default decided by the debian package.
pesho commentedon May 15, 2017
Users can still update if the tarball is used, they just have to use the same method (i.e. unpack the tarball). Or, if they really really really need to use a different method, they can delete the old yarn installation first.
Updating components already included in the image (Node, NPM, Yarn) should be discouraged anyway.
We need to decide that anyway for the Alpine variant.
P.S. I tested unpacking into
/usr/localand it works fine, but looks a little messy, e.g.LICENSEandpackage.jsonend up at/usr/local. But this is also true for the way we install Node itself (which is the same), it also leaves artifacts such asREADME.mdandCHANGELOG.mdin/usr/local. I'm going to test unpacking somewhere else and symlinking in/usr/local/binnext.pesho commentedon May 16, 2017
Proposed PR to switch to using tarball: #403
Daniel15 commentedon May 16, 2017
There is! https://pkgs.alpinelinux.org/package/edge/community/x86_64/yarn. Looks like it hasn't been updated for 0.24.x yet though. Note that the Alpine package is community maintained (it's not directly published by the Yarn team)