Add Node 16 support, drop Node 12 support. Update supported browsers and documentation

[PieterGit]

Changes:

• update Node requirements. This is a follow up from Upgrade to Node 16 #7417 since @bewest already merged his branch to dev
• add NodeJS 16.x support.
• drop NodeJS 12.x support.It reached End-of-Life status on 30 April 2022
• allow NodeJS 18.x support to run for CI
• upgrade webpack and webpack-cli and webpack related modules
• update browserlist and browser documentation, config is now at .browserslistrc
• update README.md for browsers and Node versions
• fix typos in comments in lib/client/hashauth.js and webpack/webpack.config from Fixes node 16 #7440

[PieterGit]

This is work in progress. Had some problems with my dev environment. Will look into it later. Will drop Node18 support since share2nightscoutbridge and minimed are not ready for it now.

[PieterGit]

@bewest Can you please review this PR? Should I also increase the major version number to 15 since, we don't support Node 12 and now support Node 16? Thanks in advance

[bewest]

#7487 (comment)

I'd like to release pending 14.2.6 with everything in play and dev with node 12, followed by 14.2.7 release which only supports node 14.x and 16.x. This allows anyone accidentally depending on node 10 or node 12 a clean transition point via 14.2.6 as a known quantity.

[PieterGit]

@bewest First releasing Nightscout 14.2.6 with Node 10 and 12 suppport sounds fine.

According to semver thinking, I think if we drop Node 10 and 12 support we should also increase the major version of Nightscout to 15.0.0, following "MAJOR version when you make incompatible API changes". This to indicate that these older Node versions are not supported any more with Nightscout 14.

What do you propose with the other fixes on browserlist, typo's and webpack updates.
Should I create a separate PR (without Node changes) or do we merge it to dev after Nightscout 14.2.6 has been released.

[bewest]

@bewest First releasing Nightscout 14.2.6 with Node 10 and 12 suppport sounds fine.

According to semver thinking, I think if we drop Node 10 and 12 support we should also increase the major version of Nightscout to 15.0.0, following "MAJOR version when you make incompatible API changes". This to indicate that these older Node versions are not supported any more with Nightscout 14.

What do you propose with the other fixes on browserlist, typo's and webpack updates. Should I create a separate PR (without Node changes) or do we merge it to dev after Nightscout 14.2.6 has been released.
Yes, my thinking is that 14.2.6 should be released ASAP. You make some interesting arguments about the versioning that I'd like to understand better. I think I agree that it would make sense for additional changes including removing support for node 10 and 12 to target a 15.0.0 release.

[PieterGit]

@bewest wrote:

Yes, my thinking is that 14.2.6 should be released ASAP. You make some interesting arguments about the versioning that I'd like to understand better. I think I agree that it would make sense for additional changes including removing support for node 10 and 12 to target a 15.0.0 release.

If I consider Nightscout as a whole an API, then just like semver all things an API-user MUST change in order to let Nightscout work (e.g. required Node upgrades, changes to configuration that are not backward compatible) MUST also be reflected in that the major version will be incemented. I think that's quite similar to what @sulkaharo did when he bumped Nightscout from 0.13.0 to 13.0.0, https://github.com/nightscout/cgm-remote-monitor/releases/tag/13.0.0 : "13.0.1 would be a bug fix release after this and 13.1.0 would mean we’ve added (backward compatible) new features". We used Nightscout 14, for major changes to the database load (required for Atlas to which all users needed to migrate to).

Scaled Agiled calls the environement to the solution the Solution Context, see https://www.scaledagileframework.com/solution-context/ for details on their naming. I always increase the major version if a required thing needs to be changed in the Solution Context. In our case a NodeJS upgrade is definitely part of that.

[sulkaharo]

+1 for changing the major version number if the runtime requirements get a major bump

[bewest]

Howdy, @PieterGit, I merged your commits into dev via #7568.