Unexpected token ) as of version 4.0.5

[Screpuh]

Since the last update (v4.0.5) I receive the following error:

 forever-monitor/node_modules/minimatch/minimatch.js:4
  const path = (() => { try { return require('path') } catch (e) {}})() || {
                         ^
  SyntaxError: Unexpected token )
      at Module._compile (module.js:439:25)
      at Object.Module._extensions..js (module.js:474:10)
      at Module.load (module.js:356:32)
      at Function.Module._load (module.js:312:12)
      at Module.require (module.js:364:17)
      at require (module.js:380:17)
      at Object.<anonymous> (/usr/lib/node_modules/forever/node_modules/forever-monitor/lib/forever-monitor/plugins/watch.js:11:17)
      at Module._compile (module.js:456:26)
      at Object.Module._extensions..js (module.js:474:10)
      at Module.load (module.js:356:32) (ElasticBeanstalk::ExternalInvocationError)

[isaacs]

What node version are you using?

[Screpuh]

v0.10.48

[isaacs]

That is an incredibly old node version. You need to be able to use ()=>{} syntax these days, I'm sorry.

If you're using such an ancient node version and unable to upgrade it, you'll have to lock all your dependencies and only upgrade them very carefully.

[msieurtoph]

Hi, @isaacs
I understand your point of view, and I agree in the principle.
But some old systems run on these really old versions, and there's no time/money/commercial interest to migrate them ... because they still are working well.

using ()=>{} syntax is kind of a breaking change.
It means you broke backward compatibility with those old nodejs and you know you cannot bring this in a patch version.
And, I may be wrong, but I think we cannot lock dependencies of dependencies of dependencies with old npm version, then your work-around is not applicable.

IMO, you must revert these commits on the 4.0.x branch (and release a new 4.0.6, iso 4.0.4) and move all your 4.0.5 changes to a 5.x.x branch (maybe a 4.1.x, I don't know).
This way, you won't break anything for old systems builds.

Or else, please tell us how to lock nested dependencies, without manual action during npm install, with the old npm that came with our old nodejs (npm version 1.4.12 in my case).

[Tirpitz]

Or else, please tell us how to lock nested dependencies, without manual action during npm install, with the old npm that came with our old nodejs (npm version 1.4.12 in my case).

You can do what I did: run an npm shrinkwrap, open the npm-shrinkwrap.json that has been generated and change the minimatch version to 3.0.4. It fixed our Jenkins build for us.

BTW, I wanted to open an issue too on Monday when this happened, but luckly I found this fix.

IMO @isaacs, you can't just update 2017 code "up to today standards" without thinking "oh wait, there are older application that uses this". I mean, I don't even know what this minimatch does, it's just a dependecy of a dependency of a dependency that I have in the package.json. And I wish I could just update my node version, but this application I'm working on it's pretty "closed": It's an older custom maven archetype, made back in 2017 by a bank here in Italy. Now they have made a new archetype, with Angular8, which all the new applications are being made with, but I doubt they want to spend the time and money to port this application (which took 3 years to be ported from and even older desktop application) to this new framework.

Always think of legacy support. In a perfect world I could update an Angular2 application to the latest version, but unfortunately it isn't like that. For me, you can leave it like this, I fixed the problem on my end, but next time, please be careful on what you update, especially if it's really old stuff. You can never know what you're going to break.

[msieurtoph]

@Tirpitz the workaround does not work.
shrinkwrap is not supported by very old npm (at least mine, which is 1.4.12)
Thx for sharing anyway.