Travis builds fail with node 6 and yarn

[RobbieTheWagner]

It seems that ip-regex sets an engine that is not compatible with node 6, which we use for travis tests.

error ip-regex@3.0.0: The engine "node" is incompatible with this module. Expected version ">=8". Got "6.16.0"

Should we add --ignore-engines to the yarn install to avoid this sort of thing in the future? If so, I am happy to open a PR.

---

Output from ember version --verbose && npm --version && yarn --version:

ember-cli: 3.7.1
node: 11.6.0
v8: 7.0.276.38-node.13
uv: 1.24.1
zlib: 1.2.11
ares: 1.15.0
modules: 67
nghttp2: 1.34.0
napi: 3
llhttp: 1.0.1
http_parser: 2.8.0
openssl: 1.1.0j
icu: 63.1
unicode: 11.0
cldr: 34.0
tz: 2018e
os: darwin x64
6.5.0-next.0
1.13.0

[rwjblue]

Can you say more? Do you mean that ember-cli itself is failing, apps are failing, addons are failing, etc?

[RobbieTheWagner]

@rwjblue this was a couple of my addon builds, but this could be an issue with any project generated with ember-cli, I think. Seems like a dependency of a dependency, ip-regex, is causing the build to fail with:

error ip-regex@3.0.0: The engine "node" is incompatible with this module. Expected version ">=8". Got "6.16.0"

[rwjblue]

In one of the affected systems can you npm ls ip-regex? Who is pulling it in as a dependency?

[RobbieTheWagner]

@rwjblue the output from that seems to be empty, so no idea 😂

You can see the error in the build here https://travis-ci.org/shipshapecode/ember-math-helpers/jobs/478394676

Something in travis specifically must be pulling it in. It's not in my local yarn.lock

[rwjblue]

@rwwagner90 makes sense, note that CI is running yarn install --no-lockfile (which means its building a fresh lock file) so to emulate that you'd need to rm yarn.lock && yarn and check for ip-regex...

[rwjblue]

I believe that this is the same issue that @pzuraq and I were chatting about last night. Basically a nested dependency of ember-cli-addon-docs (ember-cli-addon-docs > jsdom > tough-cookie > ip-regex) is now bringing in ip-regex which is not Node 6 compatible.

See ember-decorators/ember-decorators#375 for a handy work around.

[stormwarning]

Ran into this same dependency, ip-regex@3.0.0, which was confusing since yarn.lock was specifying 1.0.3. Using --pure-lockfile instead of --no-lockfile worked since it will read from the lockfile but not try to write back to it.

</02-cents>

[Turbo87]

this is caused by salesforce/tough-cookie#140

[rwjblue]

Closing here as there isn't much we can do about it in ember-cli itself...

[RobbieTheWagner]

@rwjblue I was thinking we could add --ignore-engines to the default yarn blueprint to fix it. Thoughts?

[rwjblue]

I'm not really in favor 🤔. Hiding the failure doesn't actually fix it...

[RobbieTheWagner]

@rwjblue sure thing. I think, in a lot of cases, engines are somewhat arbitrary though, and things really work still, but I suppose it's safer to not ignore the failure, so never mind 😃