-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support modules when targeting ES6 and an ES6 ModuleKind #4811
Changes from 6 commits
48ba708
c71a0ac
60a120f
75a5c22
f2b901a
8d6cb5f
04b0aa2
8ff551c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -76,10 +76,11 @@ namespace ts { | |
"amd": ModuleKind.AMD, | ||
"system": ModuleKind.System, | ||
"umd": ModuleKind.UMD, | ||
"es6": ModuleKind.ES6, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you do not need that. just leave target as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Internally we checked for language version like it was a module kind in a number of places. Is it just a matter of not wanting to make it able to be specified explicitly? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we do not support There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, so I'm just removing it as an option for the --module command line flag. |
||
}, | ||
description: Diagnostics.Specify_module_code_generation_Colon_commonjs_amd_system_or_umd, | ||
description: Diagnostics.Specify_module_code_generation_Colon_commonjs_amd_system_umd_or_es6, | ||
paramType: Diagnostics.KIND, | ||
error: Diagnostics.Argument_for_module_option_must_be_commonjs_amd_system_or_umd | ||
error: Diagnostics.Argument_for_module_option_must_be_commonjs_amd_system_umd_or_es6 | ||
}, | ||
{ | ||
name: "newLine", | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/var/let
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it would be better to remove
ModuleKind.ES6
, as it could be confusing to API consumers, and instead use this here:Then use the
nativeModules
boolean variable when checking below, or merely inline the expression used to compute it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please no. Not having ES6 as a module kind is all kinds of not forward compatible and causes odd checks which depend on there not being module kinds alongside specific language versions. Going forward, when we implement #4813 those forms of exports will not be ES6 compatible module emit, but can be compiled to ES6 compatible module emit. In effect, when we add an ES7 target and ES7 compatible module emit feature, we're going to need an ES6 module kind (and, to be consistent, hopefully an ES7 module kind!). Additionally, not having an ES6 module kind makes specifying that you want to emit an ES6 module style bundle for #4754 awkward. (Do I target ES6 but not specify module output type at all? That's oddly inconsistent.)
--module
is one of our few variable feature flags at present, it's time we start treating it as such. ES6 is a kind of module emit. We should treat it as such. The module format is part of the ES6 spec, true, but nothing inherently ties the feature to the ES6 target only. Right now it seems nonsensical to ask for ES6 module syntax with a target below ES6 (since we know of 0 runtimes which support ES6 modules and yet support no other ES6 features), but we certainly could emit it.IMO, having an ES6 module kind simplifies our API. When a module kind is set, it now controls the emit for the module format. Full stop.