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.

[DRoet]

Would it be an idea to corepack enable by default instead of bundling w/ yarn? I feel like this would resolve the initial complaint about the image size, no? from my understanding Corepack will only download the yarn binary when you actively use it?

This would also provide easier usage for pnpm/yarn v2+ users

[SimenB]

corepack enable might make sense! I see now that it gives 1.22.15 instead of 1.22.18, but that's probably not a huge issue. Would simplify our scripts as well. One could also say "to use yarn, run corepack enable first" and not do it automatically (that would however be a breaking change - but so could running enable automatically be as well, as we then also add pnpm. another breaking change is that YARN_VERSION env var would be wrong).

Lastly, corepack is experimental - would it still be OK to use it?

/cc @arcanis thoughts?

[arcanis]

A few points:

• I think using Corepack would be a great idea! I'd also give us some practical insight as to how easy it is to use Corepack inside a Docker image, which would be valuable once we get to move it outside of experimental.

• I'd still suggest to run corepack prepare during the image bundling, so that the default package managers are inside the image cache and can be used without network access. It doesn't improve the size aspect, but it's closer from what currently happens and thus a slightly less risky first step.

• I feel like corepack enable should be called by default. The main reason it isn't by default in the regular Node distribution is to avoid potential breakages on systems where Yarn could already be installed another way, so in the case of the Docker image (where yarn is already provided) there's little reason to have it disabled.

• "I see now that it gives 1.22.15 instead of 1.22.18" - I want to auto-release updates when package managers are updated, but haven't had time to look into that yet. There's also some push from the other Node team members to use dynamic versions rather than pin them in each Node release, so that'd solve that as well.

[dunglas]

I proposed a patch enabling Corepack and unbundling yarn in https://github.com/nodejs/docker-node/pull/1768.