fails in node --strict_mode

[bcoe]

when you run a module that depends on spdx-expression-parse.js in strict mode, things explode:

node --use_strict /Users/benjamincoe/bcoe/yargs/node_modules/read-pkg-up/node_modules/read-pkg/node_modules/normalize-package-data/node_modules/validate-npm-package-license/node_modules/spdx-expression-parse/parser.generated.js 

/Users/benjamincoe/bcoe/yargs/node_modules/read-pkg-up/node_modules/read-pkg/node_modules/normalize-package-data/node_modules/validate-npm-package-license/node_modules/spdx-expression-parse/parser.generated.js:1
k.length=vstack.length-n;lstack.length=lstack.length-n}_token_stack:function l
                                                                    ^^^^^^^^
SyntaxError: In strict mode code, functions can only be declared at top level or immediately within another function.
    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 Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:929:3

This issue effects a cascading chain of modules, it was actually brought up to me on the yargs repo:

https://www.npmjs.com/package/yargs

But it also effects @sindresorhus' popular:

https://www.npmjs.com/package/read-pkg-up

And the popular npm utility module:

https://www.npmjs.com/package/normalize-package-data

I tried reproducing the issue, and simply running newer versions of the parser used for spdx-expression-parse seems to help solve this issue -- it might just be a matter of rebuilding and publishing a patch release.

[sindresorhus]

Ugh, node --use_strict is such an anti-pattern. Nobody should be using that.

nodejs/node-v0.x-archive#7479
https://github.com/substack/node-mkdirp/issues/32

[bcoe]

@sindresorhus I don't know much about --use_strict, except for the issue being brought up on yargs.

It it worth publishing a point release, since it seems it's just a matter of rebuilding -- or should I just take a hard-line on this?

[sindresorhus]

It it worth publishing a point release, since it seems it's just a matter of rebuilding -- or should I just take a hard-line on this?

That's really up to you, but accepting this is a slippery slope. I would not. There are thousands of modules on npm that would fail in strict mode. There's no good reason to use that flag.

[kemitchell]

I've managed to reproduce in Travis build 52.

I was not aware of --use_strict. I've enjoyed learning about it about as much as I enjoy learning about new unpleasant, fatal diseases. Perhaps I'm more world-savvy for it, but if someone had asked, I'd've kept my bliss.

I'm in sympathy with whoever has used the flag and suffered its predictable results. But I'm with @sindresorhus that discouragement is the only proper prescription here, as much for their sake as anyone else's. I wish they'd come direct to me, rather than to the more popular yargs, since poor @bcoe has enough problems, and now it has to bubble its way back up again.

A patch release isn't usually much to ask, but in this case we're talking about a parser generator. It's a parser generator I love, whose contributors I respect, but I've also had some issues with it in the past. I have tests, but I wouldn't publish on green here. Not with npm CLI downstream.

[bcoe]

@kemitchell I'm happy to take a hard-line on this, if Sindresorhus and Substack are fine with closing --use_strict pulls, I'm happy to as well.

[Alphapage]

I'm sorry, but I think strict mode is the new standard.
http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-code
If your tools are not compatible with es2015 modules or classes which are always in strict mode, then those tools become obsolete and unusable.
I think you should investigate in supporting strict mode quickly, but this is just my opinion.

[kemitchell]

@Alphapage, strict mode is part of newer editions of ECMAScript, but as an opt-in feature triggered by the 'use strict' directive. ECMA does not specify global interpreter behavior, like --use_strict, that imposes strict mode on code whether it has the directive or not.

[Alphapage]

As far as I can understand from my previous link::

• Module code is always strict mode code.
• All parts of a ClassDeclaration or a ClassExpression are strict mode code.

It is impossible to use it inside es6 class or import because an error will be thrown.