Repository navigation
'--alwaysStrict' option should not 'use strict' declaration if setting with module=es2015 #11806
Description
Env
- TypeScript Version 2.1.0-dev.20161023
- with enable
--alwaysStrict&--module=es2015option
Code
Compile the below code with the above options.
export const a = 1;Actual behavior
"use strict";
export var a = 1;Expected behavior
I think "use strict" declareation is needless for ES2015 module because "Module code is always strict mode code" by the spec.
Activity
tetsuharuohzeki commentedon Oct 24, 2016
relate: #10758
mhegazy commentedon Oct 24, 2016
I agree it is invalid with
--target ES2015; but the above sample is for--module ES2015, which i do not see why it is invalid. the module code has been parsed and transformed, and the"use strict"is part of this transformation.tetsuharuohzeki commentedon Oct 25, 2016
import/exportdeclarations introduced by es2015 is only be parsed in parsing them as Module. Paradoxically, we can regards as Module as the source file which includesimport/exportdeclarations and is parsed as valid ecma262 code.kitsonk commentedon Oct 25, 2016
Modules in the ES2015 module format do not have to be loaded by the native module loader (since there is yet to be a production ready one). Having a valid module format does not always imply the code will be interpreted in strict mode. While SystemJS will load modules in strict mode when their source module format is ES2015, other bundlers may or may not do the same.
Since there is no issue extra emits of the prolog, I would say it is still best to emit code targeted at ES5 to provide the
"use strict";prolog irrespective of the module format. It minimises any surprises.aluanhaddad commentedon Oct 30, 2016
I am definitely in favor of leaving this as is.
slawomir commentedon Oct 30, 2016
Specification mentioned by saneyuki stays that modules are interpreted in strict mode. Specification means ES6 modules, so following conditions must be met to make TypeScript generate ES6 module:
--target es2015--module es2015--modulecannot be set to for examplecommonjs, because then result Javascript will not be ES6 module, and strict mode will not be assured by default in runtime.On the other hand adding
"use strict"in generated ES6 module should not cause any problems. In that case skippinguse strictfor ES6 modules would be an optimisation to result code.