Can't use shaka-player in projects that use node < 14

[caridley]

Have you read the FAQ and checked for duplicate open issues?
yes

What version of Shaka Player are you using?
4.3.4

Can you reproduce the issue with our latest release version?
yes

Can you reproduce the issue with the latest code from main?
yes

Are you using the demo app or your own custom app?
custom app

If custom app, can you reproduce the issue using our demo app?
Not applicable

What browser and OS are you using?
No relevant

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Not relevant

What are the manifest and license server URIs?
Not relevant

What configuration are you using? What is the output of player.getConfiguration()?
Not relevant

What did you do?
Tried to use shaka version 4.3.4 in a project that is currently using node 10.19

What did you expect to happen?
Expected yarn install to succeeed

What actually happened?
Yarn install of our project that uses shaka-player fail on shaka-player because shaka-player package.json has engines.node ">= 14"

node 14 is required when building the shaka-player library, but is not required when using it.

The engines.node should not be present in the package.json in the distribution

[alexandercerutti]

I think to have reported the same thing some months ago here: #4721. Is this maybe a duplicate?

We ended up upgrading Node from 12 to 14, by the way.

Anyway, Node 10 was LTS until like 2 years ago.
Now Node 14 is now at the "end of life" since the end of April 2023.

[joeyparrish]

Yarn install of our project that uses shaka-player fail on shaka-player because shaka-player package.json has engines.node ">= 14"

node 14 is required when building the shaka-player library, but is not required when using it.

The engines.node should not be present in the package.json in the distribution

This is because some of our build or test dependencies require node >= 14. Is there a way to specify engines.node separately for a dev install?

[alexandercerutti]

@joeyparrish what about something like NVM (Node Version Manager) with a .nvmrc or pnpm (which is a package manager, but also includes such NVM feature)?

I mean, that would not be strict, so you'd have to document it for development.

[joeyparrish]

Developers can definitely use NVM if they wish, but I can't imagine requiring it at a project level.

[alexandercerutti]

I meant setting NVM on Shaka through an .npmrc.

It is pretty common to have it on any kind of project. It is not one of those dependencies that should belong only to some specific kinds of projects (e.g. final products).

[joeyparrish]

Sorry, I'm not familiar with setting NVM through npmrc, and I didn't find anything obvious from a Google search. Can you give an example or link I could learn from?

[alexandercerutti]

@joeyparrish sure! Here it is:

https://github.com/nvm-sh/nvm
https://github.com/nvm-sh/nvm#nvmrc

It is easy as just hardcoding the node version inside the text file and installing NVM on your system.

Anyway, another possibility would to introduce a programmatic check like this below, but maybe by hardcoding the required version instead of reading it from package.json.

import semver from 'semver';
import { engines } from './package';

const version = engines.node;

if (!semver.satisfies(process.version, version)) {
  console.log(`Required node version ${version} not satisfied with current version ${process.version}.`);
  process.exit(1);
}

[joeyparrish]

Ah, you mean nvmrc, not npmrc. I see. Sure, that's no big deal. Send a PR if you like.

However, it doesn't seem to address the original issue, which states:

Yarn install of our project that uses shaka-player fail on shaka-player because shaka-player package.json has engines.node ">= 14"

I could be wrong, but I think so long as we have dependencies that require node >= 14, it's appropriate to have that same requirement in shaka-player itself.

But after searching through actual dependency and transitive dependency, I'm finding things more nuanced. The strictest engine setting in our dependencies seems to be from some of the eslint packages:

  "engines": {
    "node": "^12.22.0 || ^14.17.0 || >=16.0.0"
  },

In fact, the addition in our package.json only came about a year ago, in PR #4219, where it is noted that our dev deps generally require 12.

@caridley, what's your environment? Can you satisfy node >= 12? If so, I suggest someone could change our minimum to more closely match what eslint requires. (I'm guessing 12.22 and 14.17 are final releases when those branches went EOL.)

[alexandercerutti]

Ah, you mean nvmrc, not npmrc. I see. Sure, that's no big deal. Send a PR if you like.

Sorry @joeyparrish, I wrote it wrong the second time ahah
Actually .npmrc exists but it is for other purposes!

However, it doesn't seem to address the original issue, which states:

I think that having a .nvmrc would allow shaka to not have engines.node hardcoded, because .nvmrc is evaluated only on development and when developers run nvm use.

Also, I think the original purpose for engines.node is made for production in libraries, not for development. That's kind of a shame. I'd honestly prefer something tailored for development.

Anyway, IMHO, I'd not bring the engines.node down: Node 14 and lower are now out of LTS, so it should be the burden of projects that use libraries to keep up. Otherwise, every library out there would be still supporting Node 0.10, I guess.

[caridley]

There is some good discussion about modifying package.json for publishing here

https://stackoverflow.com/questions/40942495/clean-package-json-before-packing

And a reference to the following toold

https://www.npmjs.com/package/clean-package

[joeyparrish]

I'm going to implement clean-package and try to get it into our next releases.