Ability to start OS Dashboards with a newer and compatible nodejs version

[sipopo]

Description

Resolve bug the application doesn't start with nodejs version 14.20.0

Issues Resolved

[BUG] Doesn't start with nodejs 14.20.0 #2088

[kavilla]

Added details to #2088, this logic is intentional.

[sipopo]

I added warning message for minor check

[sipopo]

Hi, It is my first pull request in github. Do I need something to do else?

Sorry for my question...

[smortex]

#2101 was merged and update nodejs to 14.20.0, but the point of this PR/issue #2088 remains. I would suggest clarifying this by updating this Issue and PR subject to something like "Allow using a newer minor version of nodejs than the bundled one" or "Fix startup when using a newer minor version of nodejs then the bundled one" (since the issue is not 14.20.0 specific anymore).

At the bottom of the page, you will see 2 failing tests:

Click "Details" to see what was wrong, fix it and update the PR accordingly (see bellow for some hints). Each project is different, but the idea is usually to external contributors to work on their code and have automatic feedback, and reviewers will wait for all tests to be green before considering merging code. Until then, they may still of course help you.

You mention this is your first PR (awesome!), so it's good to know that any update you do in your branch will update this PR: you can re-write your commits and force push, and the PR will automagically update!

For example assuming you want to move your commits on top of master, sign them all to make the "Developer Certificate of Origin" check green, and rework them in a single commit (squash them), you can, from your working branch:

git fetch origin       # Download the latest code we have here
git rebase origin/main --signoff --interactive # Interactively move your commits on top of the main branch ensuring they are all signed

This will bring your editor listing all commits in your branch. Keep the first line unchanged, and replace pick with squash for all subsequent lines. Save and quit, your editor will pop again and allow you to combine all the commit messages in a single one.

Then push your updated branch:

git push -f            # Send the changes (-f is required because we re-wrote history)

[ashwin-pc]

@sipopo will you be able to add a signoff to your change? We cannot accept your change unless we have that. The PR otherwise looks great! @smortex's comment has detailed instructions on how to do so

[sipopo]

Sorry for late. I signed my commit.

[sipopo]

Sorry for my misunderstanding. I returned my changes to project )

[ashwin-pc]

@sipopo Thanks for making the change!

[ashwin-pc]

@sipopo Looks like your change is breaking a version check test.

[ashwin-pc]

So i pulled down the changes to validate if this works as expected only to run into a very interesting behavior. @sipopo @AMoo-Miki How did the two of you validate this functionality? Because when i run the yarn commands, it turns out that the first line of defense is node and package.json itself.

We have an engines key in the package.json file that fails first when we try to use any other minor or patch version of node. It does not even get to node check. The only two ways to get past this is to update the engine requirements to be something like ^14.20.0 or pass the --ignore-engines flag. Did either of you run into this while testing the feature? Also if you use the former option of specifying the node version using the caret symbol, the regex that you use is no longer valid. Here's one way to fix that:

1. Delete line 37 where we prefix v and rename rawRequiredVersion to requiredVersion. We know that this will not be null for our usecases so this is a safe assumption. And to be honest, i'm not sure that line makes any sense.
2. Modify the version regex to /^[v~=\^]+(\d+)\.(\d+)\.(\d+)/ to handle v, ^, ~ and = prefixes

With these changes, the rest of the code works as expected. I think this is also why @kavilla and @miki might have called out the initial change did not work.

[ashwin-pc]

Can you remove this change?

[AMoo-Miki]

So i pulled down the changes to validate if this works as expected only to run into a very interesting behavior. @sipopo @AMoo-Miki How did the two of you validate this functionality? Because when i run the yarn commands, it turns out that the first line of defense is node and package.json itself.

The original idea was that this piece would relax the requirement and then engines.node would use 14.20. I felt that didn't eliminate the restrictions enough and hence I implemented this very differently in #3402.

@sipopo I would have loved to add you as a co-author but due to the missing DCO in this PR, I couldn't. Thanks for all the effort you put in here; know that you were a big part of the motivation to get this done.