TypeScript is configured by using a tsconfig. json file. Enabling strict mode is as simple as doing: And what this does is enable noImplicitAny , noImplicitThis , alwaysStrict, strictBindCallApply , strictNullChecks , strictFunctionTypes , and strictPropertyInitialization under the hood.
Strict Mode(“use strict”) helps identify common issues (or “bad” parts) and also helps with “securing” JavaScript. In ES5, the Strict Mode is optional but in ES6, it's needed for many ES6 features.
You can do that by compiling with the --noImplicitUseStrict compiler option—add "noImplicitUseStrict": true to "compilerOptions" in tsconfig. json. Doing so will prevent the compiler from emitting "use strict" .
Updates
"use strict";
is emitted in modules (Read more).--alwaysStrict
compiler option parses all files in strict mode and emits "use strict"
at the top of all outputted files (Read more).You can find a list of some examples by searching TypeScript's tests for "in strict mode".
Here's some examples of code that will only throw a compile time error when you "use strict";
:
// future reserved keyword not allowed as variable name
var let,
yield,
public,
private,
protected,
static,
implements;
// "delete" cannot be called on an identifier
var a;
delete a;
// octal literals not allowed
03;
There are a few more examples where "use strict";
would throw an error only at runtime. For example:
"use strict";
delete Object.prototype;
Personally, I don't find it all that useful at preventing me from making mistakes in TypeScript and the additional noise it adds to a file makes me not bother writing it. That said, starting in TS 2.1 I'll enable the --alwaysStrict
compiler option because it adds the slight additional strictness without any code maintenance overhead.
For my money, yes, "use strict";
should be included in TypeScript files.
Disregarding the compile time effects of "use strict";
on TypeScript, there is likely a runtime impact when the generated JavaScript is executed:
MDN identifies performance improvements in avoiding boxing this
in function calls, and the removal of the function.caller
and function.arguments
properties.
Jeff Walden of Mozilla has also hinted at opportunities for performance gains in this answer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With