Switch to using Yarn tarball (or Debian package)

[Daniel15]

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)

[pesho]

@Daniel15 thanks for letting us know 👍 I'll try to prepare a PR soon(ish) to install using the tarball.

[Starefossen]

Great news @Daniel15!

[chorrell]

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]

@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/ and lib/ subfolders) into /usr/local, like we do with Node itself. @Daniel15 please correct me if I'm wrong.

[chorrell]

The yarn debian package installs yarn in /usr/local so /usr/local seem reasonable to me.

[Daniel15]

We might not want to use /opt/yarn-[version]/

It's just a tarball; you can extract it wherever you want 😃 If you like, you could extract Yarn to /opt/yarn and then symlink /usr/local/bin/yarn to /opt/yarn/bin/yarn. Depends on how you want to handle dependencies that are not installed via the package manager.

It seems to me that we can simply unpack the tarball (more specifically, the bin/ and lib/ subfolders) into /usr/local, like we do with Node itself

That should work. The tarball wasn't really built with that in mind though, so there's some files at the root (package.json and LICENSE). The Debian package essentially extracts the tarball to /usr/share/yarn/, and then symlinks /usr/bin/yarn to /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/yarn or whatever you like. It's up to you, Yarn doesn't really care where you put its files.

The yarn debian package installs yarn in /usr/local so /usr/local seem reasonable to me.

The Debian package installs to /usr, not /usr/local. /usr/bin is for executables that are installed via the system's native package management system, so the Yarn executable is at /usr/bin/yarn when installed via the Debian package. /usr/local/ is for everything that's not installed via the native package manager.

[chorrell]

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]

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]

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]

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]

I really like the debian package since it gives users an easy way to update

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.

as well as not having to decide ourself where files should be placed

We need to decide that anyway for the Alpine variant.

P.S. I tested unpacking into /usr/local and it works fine, but looks a little messy, e.g. LICENSE and package.json end 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 as README.md and CHANGELOG.md in /usr/local. I'm going to test unpacking somewhere else and symlinking in /usr/local/bin next.

[pesho]

Proposed PR to switch to using tarball: #403

[Daniel15]

If there was an Alpine yarn package

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)