deprecate --use_strict

[ghost]

This feature is antithetical to modularity because if any module in your dependency graph uses an octal literal or other sensible features your code will refuse to work and angry people will swarm on your issues thread demanding purely subjective style fixes. If people want strict more in their own code, "use strict"; is entirely sufficient.

In the words of @domenic:

Unfortunately, Node has a mode wherein it doesn't run JavaScript, but instead runs
a bastardized version of JavaScript where all code, everywhere, is put in strict mode.
The JS spec is extremely clear that strict-mode is an opt-in condition, function- or
script-scoped, and changing this semantic by forcing strict mode globally on all
scripts is a breaking change in the language. So if you use this mode you are not
programming in JavaScript, and even worse than programming in something like
CoffeeScript, you are reinterpreting all your dependencies to be written in this
non-JavaScript language.

[obastemur]

I don't know if any application may need that but for example --use_strict is very useful for basically testing JavaScript modules etc. for unintentional issues. For anyone needs custom strict mode, nodejs / v8 supports "use strict"; pretty well already.

--use_strict provides kind of a safe mode that is pretty common to software applications, frameworks, operating systems... Someone starting up an operating system under the safe mode and blaming it for not functioning properly.

[rlidwka]

I'd love to see it implemented.

I just found about 50 issues on github where people try to use --use_strict with some module, fail to do so, and think that it's a bug in there. Each one of them wastes developers time for no reason (this recent issue in express would be a nice example).

Not to mention that --use_strict would make all existing var global = function(){return this}() constructs fail without any warning.

[WebReflection]

@rlidwka var global = Function('return this')(); will always work even with --use_strict flag. Do not use the other version if your code is not under your own control, since that fails if just wrapped inside another function that "use strict" i.e. function fail(){'use strict';return function(){return this}()}

[mikeal]

this is a v8 feature isn't it? to date, does node block/remove any v8 features?

[ghost]

@mikeal Perhaps we can push this upstream to v8 then? It's a bad idea no matter where it lives. I just want to see it die.

[mikeal]

@substack I nominate @domenic to that task :P

[Raynos]

👍 on removal. Having a StrictScript weird javascript mode is annoying.

[tjfontaine]

This is indeed a problem to be handled upstream of Node, thanks for your interest though

[fulup-bzh]

--use_strict is a very nice option, it makes code easier to debug and safer at runtime. Unfortunately the fact that it is incompatible with the debugger prevent from enforcing it at a global level.

Hopefully this will be fixed future version of nodejs. But I would vote for --use_strict to be the default mode and to have --not_strict for legacy code.

[mikeal]

@domenic is there a corresponding v8 bug that we can references?

[domenic]

I think V8 uses it for testing and doesn't plan to remove it. Maybe we can lobby to get it renamed to e.g. --use_strict_only_for_testing_v8 or something: https://code.google.com/p/v8/issues/detail?id=3719

[rlidwka]

Maybe we can lobby to get it renamed to e.g. --use_strict_only_for_testing_v8 or something

My suggestion would be:

On V8 side: rename it to --v8-strict-testing.

On node.js side: introduce --strict-repl option for wrapping repl statements in strict-mode function (but all required modules should still be non-strict).

PS: maybe prefix all v8 options with v8- to make it explicit where people should report these bugs to?

[domenic]

Unfortunately it looks like V8 is not willing to change the name (or remove the option).

I still think we should blacklist it on the Node side.

[rauschma]

+1 for --strict-repl; it’s nice to have a simple way to try out strict mode stuff in the REPL.

[ljharb]

Any modern interest in blacklisting this flag on the node side?

[ChALkeR]

@ljharb Perhaps this should be discussed at nodejs/node instead?

[ljharb]

@ChALkeR thanks, done nodejs/node#6429