Support for engines field in package.json to determine supported Node.js versions

[almereyda]

After the Feature Request `engine` field in `package.json` - Feature Requests - PKP Community Forum automatically closed itself, I'm trying to submit the subject as a "Technical Proposal" again.

Describe the problem you would like to solve

As a systems engineer, I need the OJS package to communicate to me its supported versions of runtime and build components, in order to derive reproducible artifacts from tagged source code releases.

I would like the metadata of the Node.JS package for OJS to tell me which versions of NodeJS are supported. This might help to avoid errors when running npm run build with OJS 3.3 on Debian Bookworm through Node 18.

Describe the solution you’d like

Use the engines field in package.json.

This information can also help to build a version compatibility matrix.

Reference examples:

• Release Components - Version Support - The Cluster API Book
• Version Skew Policy | Kubernetes

Who is asking for this feature?

Software Engineer

Additional information

# npm run build

> [email protected] build
> vue-cli-service build --no-clean


⠸  Building for production.../var/www/html/ojs/node_modules/loader-runner/lib/LoaderRunner.js:106
                        throw new Error("callback(): The callback was already called.");
                              ^

Error: callback(): The callback was already called.
    at context.callback (/var/www/html/ojs/node_modules/loader-runner/lib/LoaderRunner.js:106:10)
    at /var/www/html/ojs/node_modules/css-loader/dist/index.js:141:5

Node.js v18.19.0

---

A workaround has been presented to build the frontend with:

NODE_OPTIONS=--openssl-legacy-provider npm run build

cc @asmecher

[asmecher]

@almereyda, I had passed the forum thread on to someone who's better with the JS ecosystem than me -- I linked the forum thread over here for when they're able to catch up.

[jardakotesovec]

I agree that this would be useful information in package.json.

But in this particular scenario, I wonder whether better improvement would be just adjust the package.json to use the flag that Alec mentioned above. As I also happily use Node 22 to build ojs 3.3 using that flag.

    "dev": "NODE_OPTIONS=--openssl-legacy-provider vue-cli-service build --no-clean --watch",
    "build": "NODE_OPTIONS=--openssl-legacy-provider vue-cli-service build --no-clean",
    "lint": "NODE_OPTIONS=--openssl-legacy-provider vue-cli-service lint js/load.js lib/pkp/js/load.js lib/pkp/js/classes/VueRegistry.js"

[jonasraoni]

Fully agreed, there are also other options, such as:
https://github.com/toddbluhm/env-cmd

[almereyda]

To note, it just feels wrong to use a flag such as --openssl-legacy-provider, being completely aware that running a depreciated Node.js version instead yields the same effect.

[asmecher]

@almereyda, I think this is only required for 3.3; things have already been updated in 3.4 and forward. We're going to be deprecating 3.3 in favour of the new LTS soon enough, so I'd prefer not to upset things more than necessary.

[almereyda]

Thanks. I see what you mean. Probably the support for the 3.3 line has already been stretched and stressed enough.

Do you have a visual overview of releases with shorter and longer term support, very much like on https://nodejs.org/en/about/previous-releases#release-schedule?

[jonasraoni]

https://github.com/pkp/ojs?tab=security-ov-file#readme