Repository navigation
Separate variant including yarn #777
Description
Activity
I think that'll be hurting since:
node-yarnhas 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 withyarnyarnis quite stable already @v1.x.xand peforms quite on-par withnpmthese days- there are quite some issues with
npmthat aren't present when usingyarn- personally experienced this before, which made me switch toyarn yarnbinaries are truly really small, like come on man includingyarnin this image is one of the greatest gifts ever please don't take it back haha
Reacted by IgorReacted by Rudolf BykerFWIW, we're looking into creating new variant for use with multi-stage builds that does not include yarn or npm.
Reacted by Cyril Auburtin, Utkarsh Gupta, Örjan Sjöholm, ⊣˚∆˚⊢, Christian Vadalà, Geordie J, Casey Burnett, Sylvain Dumont and dcharbonnierReacted by ⊣˚∆˚⊢, Alf Eaton, dcharbonnier and Przemysław ZalewskiYeah, 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)
Reacted by xemasiv, Cyril Auburtin and IgorI 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
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.
Reacted by Nick Schonning, Cyril Auburtin, Geordie J, Julian Claus, Przemysław Zalewski, Tanguy Krotoff, Loren Yu, Philip Dubé and IgorAs @SimenB,
yarnis used by a significant portion of thenodeecosystem, 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 havenpmoryarn), but until multi-stage builds are supported for official images, I think that will be tough to get the full benefits from (see #404 )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.
Reacted by Nick Schonning, Tianon Gravi, Przemysław Zalewski, Tanguy Krotoff and Loren YuReacted by Tobias FaustWhy don't we just make some tags then?
Likenode:12-npm,node:lastest-yarn,node:13-alpine-pnpm,node:lts-base(no package managers).CC: @nschonni
Reacted by Sergei Lobanov and Igor@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 I know it's possible in general but not necessarily with our setup.
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@daveisfera my example falls into category number 2!
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
Reacted by Jordan Harband and Przemysław ZalewskiI'm not sure we are ready to take on another of these breaking changes
Yeah, if it happens, I think it would need to be like the OnBuild deprecation that lived until the 8 release line end
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.
Reacted by Peter Petrov, Stefan Probst, Dave Johansen, Victor Vlasenko, David Daniel, maggie44, Gustav Bylund, Akihiro Nagai and Loren YuWould it be an idea to
corepack enableby 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
Reacted by Jordan Harband, Scott Humphries and Akihiro Nagaicorepack enablemight make sense! I see now that it gives1.22.15instead of1.22.18, but that's probably not a huge issue. Would simplify our scripts as well. One could also say "to useyarn, runcorepack enablefirst" and not do it automatically (that would however be a breaking change - but so could runningenableautomatically be as well, as we then also addpnpm. another breaking change is thatYARN_VERSIONenv var would be wrong).Lastly,
corepackis experimental - would it still be OK to use it?/cc @arcanis thoughts?
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 prepareduring 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 enableshould 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 (whereyarnis 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.
Reacted by Simen Bekkhus and Kévin Dunglas-
Corepack removal decision
I suggest to close this issue, since it is resolved by PR #2422 for upcoming Docker images based on Node.js 26 and above (see Yarn v1 Classic bundling). These images will not include Yarn.
To avoid introducing a breaking change into existing images based on Node.js 25 and lower, no Yarn v1 bundling change is being made to these images, and new builds will continue to bundle Yarn v1 during the corresponding lifetime of the Node.js release line that they are based on.
This relates to a discussion and decision from the Node.js Technical Steering Committee (TSC), as mentioned in #2368 (comment) after the topic was escalated to the TSC.
The discussions about adding Corepack are now outdated. Corepack was first added to Node.js and then removed from Node.js 25 onwards. See Node.js Distribution Policy > History.
Reacted by Nick Schonning and Stewart X Addison
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