Development kit and Deployment kit releases

[mhdawson]

There has been some discussion around the download and on disk sizes of our binaries (for example about npm taking up a significant portion) which got me thinking about whether it would be good to have two types of binaries available.

• Development kit - core Node.js with additional components you need for development like npm
• Deployment kit - core Node.js with components you need in production.

Having these two might allow us to be more flexible with the Development kit version where download and on disk file size might not be as important.

At the same time we could use some of the size advantage gained by removing development components from the deployment kit to offset additions on the diagnostics side (node-report, etc.) that we feel should be part of what is always available in core.

As long as the 2 options and our assumptions about their usage fit real-world usage it could be a win. The downside of course would be having to build 2 versions although that might be just be building the larger one and then stripping out components for the Deployment kit.

Thought I'd open this to see what other people think?

[richardlau]

The downside of course would be having to build 2 versions although that might be just be building the larger one and then stripping out components for the Deployment kit.

But at the moment that would just be npm (as everything else is baked into the node binary)? On Windows we do ship just node.exe, e.g., https://nodejs.org/dist/v10.1.0/win-x64/node.exe, but you need to go through All download options to find it.

[richardlau]

Binary size was also one of the concerns with building full-icu: nodejs/node#19214

[ckotzbauer]

What about Yarn on the official Docker images? Would that be a candidate for removal in a deployment image too? (If there are any considerations to split the images accordingly)

[bnoordhuis]

Why torture people with too many options to choose from? Bandwidth is cheap and disk space even cheaper.

[mhdawson]

@bnoordhuis we still have people raising the concern that our size is creeping upwards. If our users agree that size does not matter then I'd agree with you. I think it was one of the recent user-feedback sessions where this came up. We could consider something like a survey if we need more concrete data on this front.

[bnb]

@bnoordhuis the context I have is that disk space isn't super cheap for one of the newer and stronger use cases for Node.js at present: Serverless. The increasing binary size (largely due to budling npm, as far as I understand) lengthens the startup time of cold starts.

[bnoordhuis]

@bnb I don't understand your comment. If by "serverless" you mean something like AWS Lambda, then the size of our binaries is irrelevant because that's not what AWS uses.

we still have people raising the concern that our size is creeping upwards

@mhdawson Okay, but what people and why is that their concern?

[mhdawson]

@boneskull can you chime in here in terms of concerns from the tooling side? I think we heard some concern about the size of the downloads/extracted size on disk from the tooling user group.

[boneskull]

It crosses over a bit into “embedding Node.js” territory, but the issue was:

1. Native modules historically need a specific version of the Node.js executable to avoid compilation
2. Node.js needs extra stuff to compile native modules on Windows
3. Everything in the release package except the node executable, and including npm, is not needed (for the Titanium use case; presumably since all dependencies are bundled anyway)

So if you are distributing Node because your app is built with it, and you don’t expect end users to have Node installed, and you want to use native modules in your app... downloading and installing extra cruft just for the executable is evidently a poor experience for end users

[bnoordhuis]

downloading and installing extra cruft just for the executable is evidently a poor experience for end users

I have no problem with a node+npm and node-only tarball, we already do that for Windows.

However, it sounds like @mhdawson is proposing a different kind of differentiation.

[mhdawson]

My description was

• Development kit - core Node.js with additional components you need for development like npm
• Deployment kit - core Node.js with components you need in production.

I think today those would map to node-only tarball, and node+npm except that there might be things like the inspector we might only include the node+ tarball.

[bnoordhuis]

I was referring to this:

we could use some of the size advantage gained by removing development components from the deployment kit to offset additions on the diagnostics side (node-report, etc.)

That's differentiation, isn't it? I interpreted your comment as saying we bundle it with the deployment kit but not the dev kit.

[mhdawson]

The Diagnostic WG has consensus that node-report should be part of node core, so the plan is to move it into the node binary. So at that point, the specific example would no longer apply. Having said that the concept of including tools that are needed in production still applies, so I guess that is a bit different than node executable only. Possibly also an argument to move those things into the binary itself though.

[bnoordhuis]

Possibly also an argument to move those things into the binary itself though.

Agreed.

[Daniel15]

This sounds very similar to what some other languages do. For example, Java has the JDK for development and JRE for just the runtime. Similarly, .NET has the .NET Core SDK for building apps, and the .NET Core Runtime if you just want to run them. However, one of the main differences with those languages is that they're compiled, so there's a significant difference in disk space usage between the two (SDK contains the compilers, runtime doesn't). The difference would be less significant with Node.js.