Docker-node: Separate variant including yarn

[caub]

I think the nodejs image should'nt contain yarn, for projects and developers not using yarn, which is very likely the majority

related: https://github.com/nodejs/docker-node/issues/243

yarn adds 4436kB to the image

[xemasiv]

I think that'll be hurting since:

1. node-yarn has been deprecated @ https://hub.docker.com/r/yarnpkg/node-yarn/, hence a good fraction of the community already have the assumption that this image comes with yarn
2. yarn is quite stable already @ v1.x.x and peforms quite on-par with npm these days
3. there are quite some issues with npm that aren't present when using yarn - personally experienced this before, which made me switch to yarn
4. yarn binaries are truly really small, like come on man including yarn in this image is one of the greatest gifts ever please don't take it back haha

[chorrell]

FWIW, we're looking into creating new variant for use with multi-stage builds that does not include yarn or npm.

[SimenB]

Yeah, I think it makes more sense to have a version without either of the package managers rather than excluding one of them. Multi-stage builds should be good enough when we get to it (or just do rm -rf /opt/yarn-v* if you wanna remove it now).

~40% of all npm registry downloads goes through yarn, so it's not like it's a niche use case. (https://twitter.com/cpojer/status/988955951301570560 as source, https://stats.yarnpkg.com/ seems down)

[caub]

I made my own fork https://github.com/caub/docker-images#node, since I don't think we can agree about having npm and not yarn in the main node images

19% size gain on the slim variant

[ljharb]

fwiw i agree; the official node docker image should map to what node officially ships, which by default is npm and not yarn. Whether it’s niche or not is irrelevant; if it’s too niche to ship with node, it’s too niche to be on the official node docker image.

[daveisfera]

As @SimenB, yarn is used by a significant portion of the node ecosystem, and it only adds 5.5MB to the docker image (less than 10% of the alpine image size and even less for the debian bases), so I think that cost is well worth the convenience it provides.
I'm all for a variant that is "node only" (i.e. doesn't have npm or yarn), but until multi-stage builds are supported for official images, I think that will be tough to get the full benefits from (see https://github.com/nodejs/docker-node/issues/404 )

[ljharb]

The size is not the issue nor the convenience. The default node docker image must not ship a package manager that neither the OS nor node ships - it’s wildly inappropriate for that decision to be made unilaterally for a single “official” node distribution (and not for all of them).

If anything, the variant should be the one with yarn, as that is the one that deviates from node’s official default.

[jjangga0214]

Why don't we just make some tags then?
Like node:12-npm, node:lastest-yarn, node:13-alpine-pnpm, node:lts-base(no package managers).

CC: @nschonni

[LaurentGoderre]

@tianon is it possible for the build to use multi-stage build? One way we could do this is have the current images which are the full ones and then create other images that just copy the part of those images a la

FROM alpine3.10

COPY --from=node:12-alpine3.10 /path/to/node

[caub]

yes, example: https://github.com/brigand/jellobot/blob/master/src/plugins/js-eval/Dockerfile

[LaurentGoderre]

@caub I know it's possible in general but not necessarily with our setup.

[daveisfera]

Just keep in mind that multi-stage builds are still early in their support and have some caveats:
https://github.com/docker-library/faq#multi-stage-builds

[LaurentGoderre]

@daveisfera my example falls into category number 2!

[nschonni]

I think even if the multi-stage stuff works here, it would make sense for the Yarn org to have a repo for the images that builds on top of these images. EX: that would give them control over their own versioning and patching of the images, vs. the current policy of just updating the Yarn version here when the NodeJS release is cut

[LaurentGoderre]

I'm not sure we are ready to take on another of these breaking changes

[nschonni]

Yeah, if it happens, I think it would need to be like the OnBuild deprecation that lived until the 8 release line end

[SimenB]

As far as I know, nothing has changed since we added it to the image almost 3 years ago, and I don't see why anything needs to change now. It's (still) by far our most requested feature, together with an alpine image. There's no real maintenance burden for us at this point, so I don't understand why we'd want to disrupt almost half of our users by changing this.

Node doesn't officially support running on alpine either, yet we have that image. As long as the TSC (or something like it) doesn't come and say "hey, we don't want this is as an official distribution" I'm strongly against removing yarn (or alpine) at this point.

---

I still think the correct solution here is distributing a version without either npm or yarn, and recommending multi stage builds.