package.json "engine" is too restrictive

[chandlerprall]

The node version in the package.json's engines field is too restrictive to include elastic-charts in other projects. For example, EUI's CI breaks when trying to add elastic charts as we are not on that exact 10.15.2 node version. Even if we were to update and track this version requirement, we'd be forcing all consumers of EUI to use that specific node version, even in non-Kibana use cases.

[markov00]

Hey @chandlerprall
I think we need to change the .nvmrc config instead.
Quoting https://docs.npmjs.com/files/package.json#engines

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

So I think it's our .nvmrc that create issues with the CI

[markov00]

...and rethinking about my last comment, it's also more strange because the .nvmrc is not inside the distributed package, but only on the repo

[markov00]

ok so actually that note is only for npm and doesn't apply to yarn.
On yarn the that thing is only applied when passing --ignore-engines
Let me check to what version we can downgrade to satisfy our packages and I will update the library

[chandlerprall]

Thanks for looking into the npm-yarn differences! I'd also note:

• if we were using npm, I would prefer users of EUI not getting even a warning message
• with yarn, I don't think it would be good developer experience to recommend (or require!) --ignore-engines be used by consumers

[markov00]

So I've investigated a bit more the issue, here my findings:

• as part of our devDependency we are using commitizen that has a strict engine require of node >=10 https://github.com/commitizen/cz-cli
• when you execute yarn on the CI, yarn download the linked dependency of a direct dependency (in your case the dependencies of @elastic/charts) using yarn --production
• the issue is: yarn resolved the devDependencies to create deterministic build between prod and dev builds Yarn --production tries to resolve devDeps as well yarnpkg/yarn#3630
• this goes in hand with this issue: yarn install --production does an engine check on devDependencies yarnpkg/yarn#5796 where yarn --production does the engines check on dev dependency

So the problem now is: it doesn't matter if we remove the engines configuration on the release package.json, we also have to get remove of the commitizen dependency at least. This, btw, will not completely create a deterministic build because there can maybe be shared dependencies between the existing packages.

Maybe the solution is completely remove the commitizen CLI from the package. @nickofthyme what do you think?

[jbudz]

Hmm - related, I'm trying to upgrade kibana's node version now and it's being blocked on this. It looks like CI is installing kibana w/ a circular depdency on node version mismathes now :). LMK if I can help

[jbudz]

Maybe engines in this repo could indicate what versions of node this package supports, so it would be >=10 or something?

[markov00]

🎉 This issue has been resolved in version 11.1.2 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[markov00]

Hey @chandlerprall we changed the engines to a less restrictive version >=10.
We cannot easily go down to version 8 because was required by commitizen. We need to keep the commitizen adapter in the package because it's required, but this will pull in the commitizen lib with the node >=10 requirement

[chandlerprall]

@markov00 was there no luck/success with publishing the package with no engines field?

[nickofthyme]

Just to update per slack conversation

• Keeping engines at node@10 for the meantime
• Long term solution switch to yarn workspace and remove engines altogether

To discuss with @markov00 when he returns