What's our Node.js versioning strategy?

[ehmicky]

What's our strategy for Node.js versions?

This issue is not about how do we implement it (transpiling, etc.) nor which specific version we want to target, but about the requirements, i.e. what do we need to support from a business/end-user standpoint?

We have three parts that could be thought independently when it comes to Node.js versions:

1. Our code
2. User's code (build commands and lifecycles)
3. Plugins code

At the moment those three parts use the same Node.js version. Since we run each of those parts in different processes, we could technically use different Node.js versions so they are decoupled in that respect.

The reason is that each part has different business requirements:

1. Our code should probably use the latest Node.js versions:
   a. To benefit from security fixes. Node.js security patches only apply to the latest minor/patch versions of each major release. Being stuck on let's say 8.3.0 means we don't get any of those.
   b. To benefit from the speed boost of the new V8 releases. Newer Node.js releases can be significantly faster.
   c. To be able to update our dependencies. Most dependencies follow the Node.js release cycle. For example most libraries have now dropped support for Node 6/7, and we can expect Node 8/9 to follow the same fate in about one year.
2. User's code should use whatever the user wants. We should not force them to a specific Node.js version. This is valid not only for Node.js but for other runtimes.
3. For plugins code, we want to make sure older and not well maintained plugins still work even as our main code moves forward.

For this reason, I think we should probably run those different parts with different Node.js versions. What do you think?

[DavidWells]

For this reason, I think we should probably run those different parts in different processes with different Node.js versions. What do you think?

Sounds interesting. I'm curious how this would work.

Right now, if the user sets NODE_VERSION as env var in site settings or via .nvmrc the buildbot will install and use that version of node in the image as the build commands etc run.

This is one of the reasons we need to be careful about node features/deps that won't work in older versions unless we transpile back.

If we can use newer node AND let users define the node version that sounds good. It also might be complex and perhaps can cause unforeseen issues 😅

[ehmicky]

I think this is doable. I have actually a project that does just that (although other projects would also work just fine).

What about plugins? Some possibilities:
a) plugins use the same version as users code
b) plugins use the same version as our code
c) each plugin specify its own version
d) the maximum common version of plugins is used for all plugins. If none is found, an error is triggered.
e) other ideas?

[DavidWells]

Hmmm not sure.

There are other impacts this will have for example: the different versions of node will need to be downloaded + installed. This could add to build times and stack up quickly.

Maybe the answer is to go node 8+ and not support these edge cases.

if (node > 8) {
 // do cool new stuff, support plugins, lifecycle etc
}  else {
 // just exec `build.command` like old build
 // console.log('Hey there is a new build in town for node 8+. Upgrade today! http://link-to-docs.com')
}

[ehmicky]

Only c) (each plugin specify its own version) would require installing additional Node.js versions for plugins. For a) and b) we would already have that Node.js version installed.

Besides, Node.js executables could be (and probably should be) cached once for all users to avoid downloading them. This would also prevent network connectivity potential issues.

From your answer, I am taking that you were commenting on b), i.e. the Node.js version used by the plugins is the same as the version used by our core.

One potential issue with this is that plugin authors will have to upgrade when we upgrade. So this would force us to either not upgrade our core Node.js version, or to stop supporting plugins that don't upgrade.

This also means plugin authors need to be in sync with us. Plugin-based libraries like ESLint, Gulp, etc. are in a different situation because users can choose which version of the core they want to use. Our users don't have that choice, they always get the latest version of netlify/build.

Since installing a specific plugin is a user choice, should plugins use the same version as user's code instead?

• the Node.js version used by a user (e.g. with a .nvmrc) is the one used by plugins
• plugins declare their supported Node.js version in package.json engines.node field

This means plugin authors would need to be in sync with their users, instead of being in sync with us, which might make more sense? What do you think?

[DavidWells]

I don't think we need to tackle this just yet.

We should keep it on the radar though.

For the initial release, keeping it simple with 1 version of node should work™.

[ehmicky]

This is definitely a key question that would impact some important aspects of the architecture. There are several pending questions I have that depend on this issue to be designed first.

This also might be hard to change later on as it might break code (e.g. plugins) and not be backward compatible.

We should have a strategy there, even if we don't implement it yet.

What do you think of the following one?

1. the user specifies a Node.js version (.nvmrc, etc.)
2. that Node.js version is used for both user's code and plugins
3. our core code is using a different Node.js version.

1. and 2. are already the current situation, we just need to change 3..

This means neither users nor plugin authors need to worry about being in sync with our Node.js version. So user's code and plugins will keep working even 10 years from now.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in 1 year. It will be closed in 14 days if no further activity occurs. Thanks!

[github-actions]

This issue was closed because it had no activity for over 1 year.