Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate current node version #19154

Merged
merged 29 commits into from May 25, 2018
Merged

Conversation

mistic
Copy link
Member

@mistic mistic commented May 17, 2018

This pull request should close the issue #12976 and it's also a replacement for the one already opened #16811 (we must close the old one).

Basically this pull request will allow Kibana to check if the NodeJS version in use satisfies the one defined into the package.json.

The tests were built with jest, as required in the contributing guidelines, so currently both mocha and jest will search for unit tests inside src/utils folder.

@mistic mistic added review Team:Operations Team label for Operations Team labels May 17, 2018
@mistic mistic requested a review from jbudz May 17, 2018 00:32
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elastic elastic deleted a comment from elasticmachine May 17, 2018
@epixa epixa changed the title Node version validator #12976 Validate current node version May 17, 2018
@epixa
Copy link
Contributor

epixa commented May 17, 2018

@mistic I made a minor tweak to this title to make it a bit more clear what it was about

@mistic
Copy link
Member Author

mistic commented May 17, 2018

@epixa good one. I just left on the title the same name I have in the branch but this one it's more clear!

src/cli/cli.js Outdated
import Command from './command';
import serveCommand from './serve/serve';

const argv = process.env.kbnWorkerArgv ? JSON.parse(process.env.kbnWorkerArgv) : process.argv.slice();
const program = new Command('bin/kibana');

// Validates current the NodeJS version compatibility when Kibana starts.
NodeVersion.runValidator(() => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm thinking we'll want to run this as part of the server start process here.

  1. we'll have the standard logger available
  2. we'll have config available

there's going to be more bootstrap checks in the future and we'll have more info available at that point. the downside is we may fatal beforehand if someone's a breaking change, but i'm okay with that. thoughts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point @jbudz. Thinking about the reasons (1 and 2) you provide I really agree with you!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually like to see this check at the first possible moment (before even babel-register) because requiring a specific node version sometimes means that we won't even be able to get to the server start process without hitting a syntax error or something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if i'm honest with myself this was a ploy to provide a config for disabling the version check. in the above case

  1. syntax error, server doesn't start
  2. api has changed, server doesn't fatal, version check exits

as long as it's before any writes the worst case is a vague error, but the person knows they've been messing with things at that point.

i'm still not a fan of forcing an exact version match with no workarounds. package mangers, manual security updates and swapping distributions all seem valid to me. with that said i'm in the minority on this so lets leave it and if there's an issue we can revisit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the version check is in a module by itself we can offer a workaround 😉

echo '' > src/babel-register/node_version_check.js

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't tell anyone to change Kibana source files :P

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, by leave it as is i mean ignore my comment. i missed the module part above.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spalger that was the reason I had in my head when I first choose to run the code inside the cli file but thinking a bit better even running it in CLI won't preventing syntax errors related with babel when running in Node <= 4.

In order to fully support this behaviour I need to rewrite node_version.js as an ES5 module and run it from src/babel-register/index.js.

@spalger @jbudz @tylersmalley do you agree with it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We almost went there in https://github.com/elastic/kibana/pull/19104/files/bd0f4e1bfe41abe39f9d61caa8a583b10cc80f58#diff-202f54e3b2f5233afda1e3c964211e5d, but maybe this pushes it over the edge and it's time to create a src/setup_node_env.js module or something that combines babel-register, ts-node/register, and the node version check...

@mistic mistic force-pushed the node-version-validator-#12976 branch from 4b62802 to 3bf0ff7 Compare May 22, 2018 16:20
@mistic mistic force-pushed the node-version-validator-#12976 branch from e213b74 to 82650c4 Compare May 22, 2018 16:59
package.json Outdated
@@ -192,7 +192,7 @@
"rison-node": "1.0.0",
"rxjs": "5.4.3",
"script-loader": "0.7.2",
"semver": "5.1.0",
"semver": "5.5.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we update this to use a caret and track the most recent minor?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes ofc @tylersmalley! I have already done it.

@@ -0,0 +1,15 @@
/* eslint-disable no-var */
Copy link
Contributor

@spalger spalger May 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than overrides like this, and changes in other files that aren't enforced with eslint but are designed to ensure the node_version check can run before node craps out...

I think we should split this eslint config override into two:

  1. files that run before the node_version check and aren't allowed to use things like let, const, or destructuring syntax
    • scripts/*
    • src/setup_node_env/*
  2. files that are not babel-ified but run after the node version check and can use anything except import

@@ -0,0 +1,3 @@
require('./node_version_validator');
require('./ts_node_register');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets keep the ts-node stuff in with babel_register, with babel 7 it actually will be a part of babel_register, and I think it's important that places like the plugin helpers that are pulling in babel_register specifically get typescript support too

@elastic elastic deleted a comment from elasticmachine May 23, 2018
@mistic
Copy link
Member Author

mistic commented May 23, 2018

@spalger I have already completed the changes you requested 🎉
Let me know about your thoughts now 😎

@elastic elastic deleted a comment from elasticmachine May 23, 2018
@elastic elastic deleted a comment from elasticmachine May 23, 2018
@elastic elastic deleted a comment from elasticmachine May 24, 2018
Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, @jbudz @tylersmalley one of you want to take another look at this?

@elastic elastic deleted a comment from elasticmachine May 24, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@jbudz jbudz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me. We can probably remove the version check from yarn kbn bootstrap now too? (doesn't need to be in this PR

@mistic mistic merged commit 194aba1 into elastic:master May 25, 2018
mistic added a commit to mistic/kibana that referenced this pull request May 25, 2018
* feat(12976): node version validation at runtime.

* refact(12976): move the code into a static utilities class.

* test(12976): added first test case using jest.

* test(12976): added test cases for node_version.

* feat(12976): create setup env node to bootstrap babel, ts-node and node version validator.

* refact(12976): migrated node version code from es6 to es5.

* feat(12976): node version validation at runtime.

* refact(12976): move the code into a static utilities class.

* test(12976): added first test case using jest.

* test(12976): added test cases for node_version.

* feat(12976): create setup env node to bootstrap babel, ts-node and node version validator.

* refact(12976): migrated node version code from es6 to es5.

* fix(12976): remove one level from ts node register cache directory link.

* chore(12976): added caret to semver dependecy in order to support minor versions.

* refact(12976): small change from named import to default import on node version validator.

* refact(12976): removed ts_node_register and add the code to babel_register.

* feat(12976): split eslint config in order to properly support files built to run before and after node version validator. refact(12976): convert script files to es5 code. refact(12976): delete inline eslint configs from node version check related files.

* refact(12976): remove ts node register file.

* refact(12976): completely port setup_node_env to es5.

* refact(12976): remove babel_register invokation from external dependencies in scripts.

* refact(12976): move node_version code directly into node_version_validator inside setup_node_env folder.

* refact(12976): only node version validator for kbn script.
@mistic
Copy link
Member Author

mistic commented May 25, 2018

6.x/6.4: 229fd27

mistic added a commit that referenced this pull request May 29, 2018
* Validate current node version (#19154)

* feat(12976): node version validation at runtime.

* refact(12976): move the code into a static utilities class.

* test(12976): added first test case using jest.

* test(12976): added test cases for node_version.

* feat(12976): create setup env node to bootstrap babel, ts-node and node version validator.

* refact(12976): migrated node version code from es6 to es5.

* feat(12976): node version validation at runtime.

* refact(12976): move the code into a static utilities class.

* test(12976): added first test case using jest.

* test(12976): added test cases for node_version.

* feat(12976): create setup env node to bootstrap babel, ts-node and node version validator.

* refact(12976): migrated node version code from es6 to es5.

* fix(12976): remove one level from ts node register cache directory link.

* chore(12976): added caret to semver dependecy in order to support minor versions.

* refact(12976): small change from named import to default import on node version validator.

* refact(12976): removed ts_node_register and add the code to babel_register.

* feat(12976): split eslint config in order to properly support files built to run before and after node version validator. refact(12976): convert script files to es5 code. refact(12976): delete inline eslint configs from node version check related files.

* refact(12976): remove ts node register file.

* refact(12976): completely port setup_node_env to es5.

* refact(12976): remove babel_register invokation from external dependencies in scripts.

* refact(12976): move node_version code directly into node_version_validator inside setup_node_env folder.

* refact(12976): only node version validator for kbn script.

* Fix check_file_casing babel_register reference (#19457)

* chore(12976): fixed license headers on new files.
@k3a
Copy link

k3a commented Aug 26, 2018

I am using Arch Linux which has rolling updates so it tries to have latest packages.
After recent update Kibana won't start with
Kibana does not support the current Node.js version v10.9.0. Please use Node.js v8.11.4.

After removing this check from setup_node_env/node_version_validator.js, it started and looks quite normal.

Are you sure it is a good idea to prevent your software to work with newer Nodejs without any concrete incompatibility reason?

@mistic
Copy link
Member Author

mistic commented Aug 27, 2018

@k3a we have this kind of check because officially we only support the nove version we ship with each version (only one certain node version at a time).

@k3a
Copy link

k3a commented Aug 27, 2018 via email

@epixa
Copy link
Contributor

epixa commented Aug 27, 2018

Given that we ship the node.js binary with our Kibana distributions and that Kibana could break entirely with any node.js version that isn't the one we test against, what's the use case for running with different node versions? Is this a dev-only concern?

@mistic
Copy link
Member Author

mistic commented Aug 27, 2018

@k3a Also you don't need to remove setup_node_env/node_version_validator.js. If you need/want to run another node version than the one we support, you just need to update the package.json engines.node field to the version you want to run. However as @epixa mentioned, using a non officially supported version could make Kibana break entirely.

@Stargateur
Copy link

Stargateur commented Nov 25, 2020

#84266

that ridiculous, you are creating problem that shouldn't exist, node 10 is lts support, follow semver, there is no reason to do this. You disallow any system that follow semver.

Just put as a warning if you want not hard error !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
review Team:Operations Team label for Operations Team v6.4.0 v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants