Error installing with Yarn (node >=6.9 required)

[ashleymoogle]

Subject of the issue

Since 2.13, engine in the package.json as been set to node 6.9 (released in october...). Had to update the global version of node.js.
It makes yarn fail the install and throw this error :

yarn

yarn install v0.16.1
info No lockfile found.
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
error angular-translate@2.13.0: The engine "node" is incompatible with this module. Expected version ">=6.9".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

npm ERR! Darwin 16.1.0
npm ERR! argv "/usr/local/Cellar/node/6.8.0/bin/node" "/usr/local/bin/npm" "run" "yarn"
npm ERR! node v6.8.0
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE
npm ERR! 1001backend@0.0.0 yarn: yarn
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the 1001backend@0.0.0 yarn script 'yarn'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the 1001backend package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! yarn
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs 1001backend
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls 1001backend
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /Users/romainb/Code/1001backend-dev/npm-debug.log

npm ERR! Darwin 16.1.0
npm ERR! argv "/usr/local/Cellar/node/6.8.0/bin/node" "/usr/local/bin/npm" "run" "super-install"
npm ERR! node v6.8.0
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE
npm ERR! 1001backend@0.0.0 super-install: npm run yarn-install && npm run yarn
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the 1001backend@0.0.0 super-install script 'npm run yarn-install && npm run yarn'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the 1001backend package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! npm run yarn-install && npm run yarn
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs 1001backend
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls 1001backend
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /Users/romainb/Code/1001backend-dev/npm-debug.log

Your environment

• version of angular-translate : 2.13.0
• version of angular 1.5.8

Steps to reproduce

Have yarn, node >6.9 and try yarn add angular-translate@2.13.0

Expected behaviour

Should install angular translate

Actual behaviour

Crash, saying node should be ">=6.9"

[tspaeth]

Hi! Thanks for reporting this. If you have yarn < 0.16.0, please consider updating.
Afterwards, you can add "--ignore-engines" to your yarn add command and it will pull angular-translate correctly.

e.g.

yarn add angular-translate --ignore-engines

@knalli do we need a rollback again here for the package.json on dist and only have something like a "node >= 6.9" for development related stuff?

[knalli]

Well, at first this is a requirement for the dev stack only as the package is not using any npm package/dependency at runtime.

Said that, I see the irritations but I'm also surprised yarn actually forced the explicit defined engines -- npm does not pay such a respect/attentention: as clearly visible in the logs @ashleymoogle is using 6.8 which isn't a >=6.9 (~LTS).

It is save to ignore the warning for this package. I do not know how we can separate dev and dist without introducing dedicated packages.

[krzysieki]

I started to use yarn (version 0.16.1) and this problem occurred.

Yarn gains popularity and I suppose that this trend can only improve.

Do you really need node >6.9 for development? Most of JS features are available in node >6.

Moreover there are situations when we cant upgrade node. Some CI systems still use node max version 4.

[tspaeth]

Hm, yes, it is some harder cut maybe for the yarn users. But to get to a LTS nodeJS environment plus a 3.x npm environment - from that point, it does make sense for the developer side.
And for the yarn and user level - a workaround is described above for the current version.

[knalli]

Rephrasing my post 4 days ago: This is primarily a dev-stack runtime. I (role of a package owner) simply do not care of older versions within my dev stack flow.

That is a little bit curious, because this package actually do not have any requirement to the npm/node environment (mainly a browser env target package).

Said that, the dependency is given out because we publish this package to npm directly. Maybe we have to consider making a dedicated package.

[tspaeth]

Yup, maybe we need such a dedicated one.

[knalli]

Alternatively we remove the engine part (only in package.json, we have to leave it for nvm and travis). That's not perfect, but perhaps more comfortable?

[eddiemonge]

For the package.json having the engine that high makes no sense unless there is something in the code that absolutely breaks on node versions less than that. If it is just to run dev tests and things like that then that should be in the travis or dev runner files, not the package file.

[knalli]

As I already (2x) said: this does make sense, but for internal usage. The package definition wasn't created and made being a public published one.

Speaking of the internal package (dev stack), I simply don't want to discuss my dev dependencies with the actual users. This is nonsense, and I guess most will agree. My thoughts of removing the version will lead to situations, in wich only a nvm-user (.nvmrc) or a TravisCI (.travis.yml) will have a technically requirement. But, well, Travis is not the only one who will install them: any contributor also. And the system must be as easy as possible, some people don't read guides (which need to be refreshed separately).

Speaking of the published package, the requirement is something else. In our case, we actually don't need any requirement.

And here we go: We have a situation based on several decisions which is not comfortable. But I will not make any hasty reaction which has not being reflected enough.

---

Summarise:

1. Remove version off package.json in the main repo.
   • Pro: no issues for the users
   • Contra: Machines, developers, contributors have to check their environment manually. Travis is checked, but other tools or people not. Contribution guideline must be refreshed on each dev dependency update also. Often people just ignore it.
   • => additional support work
2. Re-locate the published package into the shadow repository bower-angular-translate, and creating a package.json init.
   • Pro: Dev stack and publishing is different
   • Contra: Unfortunately, this will create a dilemma: Until now, all files are within the npm angular-translate, but bower-angular-translate does include only the core, but not the additional loaders, etcpp. Don't get me wrong: You should use npm i angular-translate-loader-partial instead of node_modules/angular-translate/dist/angular-translate-loader-partial.js.
   • => break existing setups
3. Just remove version of `package.json for the publishing process. => sounds/looks like hacking. I'm not feeling good.. :|

[eddiemonge]

Why are you making it more complicated? You could keep it the same, remove the engines field and add a devEngines field with a check like this one https://github.com/facebook/fbjs/blob/master/packages/fbjs-scripts/node/check-dev-engines.js#L29-L61 (found from npm/npm#9765)

• Pro:
  • Keeps the existing setup, no issues for the user
  • Doesn't require a shadow repo (like the bower one which isn't really needed either)
  • Dev stack and publishing repo are the same (having them be different is a con, not a pro)
• Cons:
  • Some uses could ignore the warnings and notices. Do you really want a user like that contributing anyway though

[knalli]

@eddiemonge Thank your for that.

That's why I request for comment such things. Finally, I'm not feeling being totally wrong having such a requirement. ;) I'm fine with a custom field and an additional custom check.

[knalli]

2.13.1