[wp-trac] [WordPress Trac] #51603: Define specific versions of Node in the .nvmrc file for the 5.0-5.5 branches

[WordPress Trac]

#51603: Define specific versions of Node in the .nvmrc file for the 5.0-5.5
branches
------------------------------+-----------------------
 Reporter:  desrosj           |       Owner:  desrosj
     Type:  task (blessed)    |      Status:  assigned
 Priority:  normal            |   Milestone:  5.6
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+-----------------------

Comment (by netweb):

 Replying to [comment:16 desrosj]:
 > @netweb Thanks for this! That sounds good to me. I plan to step back
 after 5.6 and take a wider inventory of NodeJS in branches 3.7+ and trunk
 and come up with a plan of action. NodeJS < 6 is also a blocker for
 backporting the local Docker environment back to 3.7-4.5 as the needed
 packages do not support those versions. I think we can do that in a
 separate ticket.
 >

 The latest LTS release of Node.js should be used for **all supported
 branches** that continue to be maintained which are from the 3.7 branch
 onward, at the time of writing [https://github.com/nodejs/Release#release-
 schedule the latest LTS release of Node.js is v14.x]

 The `.nvmrc` file in each branch from 3.7 onward should all use `lts/*`
 (or add an `.nvmrc` file if it doesn't exist currently), nvm aliases
 `lts/*` to the latest LTS Node.js release ( See [https://github.com/nvm-
 sh/nvm#long-term-support here])

 All supported branches should have the same `.nvmrc` file that is used in
 `/trunk`:
 > https://core.trac.wordpress.org/browser/trunk/.nvmrc


 Replying to [comment:16 desrosj]:
 > For the time being, I am thinking that the `.nvmrc` file should be
 updated when a new version is branched. So when 5.6 is branched, the 5.5
 branch becomes "unmaintained" except for security releases, so the
 `.nvmrc` file should be changed to specify a specific version of NPM to
 ensure anyone working with that branch is able to build without having to
 perform archaeology.

 No, not really, NPM do not support legacy releases of NPM, the only
 supported releases of NPM are the latest releases, this has recently
 switched to v7 of NPM, though v6 of NPM will be maintained for I expect a
 period of time until v7 is considered stable and reliable.

 To be able to build an older WordPress branch, for example 3.8 release,
 here's the `package.json` tag
 https://core.trac.wordpress.org/browser/tags/3.8/package.json, in the
 latest commit to that file the commit message is:
 > "Temporarily switch to a pinned version of grunt-cssjanus. This in turn
 temporarily pins cssjanus to a patched fork."

 The above is an example of that "archaeology" we want to begin to avoid

 By continuing to use the versions set in this `package.json` file there
 are known bugs in CSS & JS minification that continue to be shipped with
 each release of the WordPress 3.8 branch, however if the 3.8 branch was
 using NPM v7.x & Node.js v14.x with the latest versions of the CSS & JS
 minification packages then these known bugs would be resolved and no
 longer shipped in the next release of the 3.8 branch which would resolve
 known bugs from ~7 years ago that continue to be shipped in each 3.8.x
 release at the moment.

 Another example is WordPress 3.9
 https://core.trac.wordpress.org/browser/tags/3.9/package.json, in this
 example it will install `grunt-sass` version `0.10.0`, this package
 requires `node-sass` version `0.8.0`, The Node-SASS package
 [https://github.com/sass/node-sass#node-version-support-policy no longer
 builds the binaries for unsupported releases], the oldest binaries
 available are for v4.5.3 from 3 years ago, v0.8.0 was released 6 years
 ago, [https://sass-lang.com/blog/libsass-is-deprecated LibSass and Node
 Sass are deprecated] and it is recommended to [https://sass-lang.com/dart-
 sass use Dart Sass] instead.

 The above are just two examples, changing the versions of Node.js and NPM
 that were used when the WordPress branch was released requires being able
 to dig through this type of "archaeology".

 To not have to done any "archaeology" gear, we should update all the
 supported branches 3.7 thru 5.6 to use Node.js v14.x and NPM v7.x

 To do this, for WP 3.8 `grunt-cssjanus` package would be replaced with the
 same RTL CSS package used in `/trunk` `grunt-rtlcss`, this brings the RTL
 CSS improvements over CSSJanus to the users still using WP 3.8. For WP
 3.9, `grunt-sass` would be updated from `0.8.0` to `3.1.0` and the latest
 Dart Sass instead of LibSass/Node-Sass

 Likewise for any other Node.js packages, if the old WordPress branch uses
 an old version of a package it can be upgraded to the latest, or changed
 to what is now used in `/trunk` where new and improved packages have been
 chosen (E.g. The switch to RTLCSS from CSSJanus)

 Doing this we patch the known bugs in the the next releases of legacy
 branches, CSS & JS bugs in WP 3.8.36, SCSS CSS compiled by Dart Sass in WP
 3.9.34, and so on through each of the supported branches.

 Even the `@wordpress/scripts` package can be added to the WordPress 3.7
 branches

 Further, every supported branch of WordPress 3.7 thru 5.6 and beyond will
 have these features:

 - Every branch uses the latest LTS Node.js and NPM release
 - There is no need for any developer or maintainer to have to switch
 Node.js versions when checking out a branch
 - The ''build'' servers only need support the latest releases of Node.js
 and NPM, the ''make/systems'' team no longer have to maintain specific
 versions of Node.js and NPM on the w.org ''build'' for each branch
 released.
 - A common set of Grunt, Node script commands for each branch, e.g. `npm
 run lint`, `grunt lint, etc (Composer scripts too)


 The above, is what I envision as to how to remove the build tool
 "archaeology" in all aspects, for good, it's been blessed by Nacin and
 Dion for years, we've just never gone ahead and actually done it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51603#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform