I cancelled the branch build since the PR build should be good enough. In the future I'll do PRs from my fork.

Also note that I have not update the README.md yet to document this new variant.

Just curious about if the npm comes with nodejs release, do we need to remove it.

I think it makes sense to remove both. Multi-stage builds really removes the need for them, and allows people to get really small images.

@chorrell thoughts on having a core version for alpine as well? People pick alpine since it's tiny, making an even smaller version makes sense to me. Can of course be done in a follow-up!

@chorrell thoughts on having a core version for alpine as well? People pick alpine since it's tiny, making an even smaller version makes sense to me. Can of course be done in a follow-up!

Indeed, a core version for Alpine would be most useful. To avoid building twice, maybe the alpine image could be built FROM alpine-core?

@pesho wouldn't that mean installing node, removing npm, then create another image to add back npm?

@LaurentGoderre exactly. Is there another viable alternative?

I think it would be cool to change the tags to have 8-alpine-dev to have npm and yarn and 8-alpine to not have either. That would be a huge change and would probably cause a lot of grief.

Building an alpine image without npm is easy enough I guess, but I'm generally 👎 about creating an alpine core image. I'd be more convinced if we had official MUSL/alpine binaries to use but until then I think we need to be honest with ourselves and our users about the level of support they can expect when it comes to Alpine.

There have been external requests for an alpine-core images... which could be made with the single change of ./configure --without-npm

/cc @mhart who manages https://github.com/mhart/alpine-node and may have opinions

Just to make sure, is "Node.js core" something that has the intended meaning with upstream too? (ie, will Node.js users already be familiar with that as a term, or is this an entirely new construct? the discussion in nodejs/Release#341 seems to imply that this is still a little bit in flux, so it might make sense to make sure the larger Node.js project is on board with the "core" name before committing to it too much)

+1 to what @tianon just mentioned. I find the use of the term core here a bit confusing as "node core" is already something we use to describe... well node 😅.

Is there a reason to avoid using tiny?

I chose the name arbitrarily. I’m open to alternatives.

Other alternatives: base, light, basic, simple

Or even copy debian: slim 😸

Also, I don't see any alpine images here – wouldn't they be the most... tiny?

Yes, but but I didn't include them for reasons noted in #808 (comment)

Mostly just curious (not asking for more work!): What's the status of this PR?

No consensus on what it should be called I think.

Anything I can do to help push toward getting consensus? 🤗

@bnb I personally don't care what the name is, seems like something the node core collaborators should decide on?

I propose minimal / mini for the tag naming, and I hope this will land with whatever name asap

I would suggest we avoid words related to size as part of the name. What would happen the day we make it smaller than tiny or minimal (eg, stripping debug symbols)? A better approach would be expressing functionality (which core does better but has conflict as brought up by @MylesBorins). Would bare fit the bill?

Edit: also, I think core or bare or whatever it ends up being should rather be a per-distro option (in a way, similar to how slim works) or limited to for instance alpine where trade-offs for size and functionality have already been made.

I foresee some problem with the base image being use (the same way we had issue transitioning the default tag from jessie to stretch.

I would be tempted to use a suffix like -nopm (No Package manager) or -xpm (Excluding package managers) and have a version with that suffix for each variant.

We could also use the same image and add an ARG for nopm or xpm and run the removal of npm if it's true and not run the YARN install if it's false.

mhart/alpine-node has a base tag for this https://github.com/mhart/alpine-node

mhart/alpine-node have a base tag for this https://github.com/mhart/alpine-node

It's not quite the same thing – that's a static build which might not work with native modules. The third example here is basically what's being proposed here, I think: https://github.com/mhart/alpine-node#example-dockerfile-for-your-own-nodejs-project

I won't be able to carry this forward. If someone else want's to take this on, "base" is probably a better name than "core"

too bad

here's a workaround: https://github.com/brigand/jellobot/blob/master/src/plugins/js-eval/Dockerfile#L8, but a node core image would have made things simpler for the final image