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: #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 #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