Revised ES6 modules #2460
Merged
Revised ES6 modules #2460
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR also fixes #2451. |
|
Also fixes #2383. |
| @@ -123,7 +123,7 @@ module ts { | |||
| case SyntaxKind.ExportDeclaration: | |||
| return "__export"; | |||
| case SyntaxKind.ExportAssignment: | |||
| return "default"; | |||
| return (<ExportAssignment>node).isExportEquals ? "export=" : "default"; | |||
There was a problem hiding this comment.
this is a fairly odd name to give this entity. Is it used elsewhere? if so, we should put it in a common location so we don't have magic strings like this floating around.
There was a problem hiding this comment.
It needs a name that can meaningfully be shown in error messages (such as duplicate symbol 'export=' when there is more than one). It is used in a few other places, but so are all the other ones here.
Conflicts: src/compiler/checker.ts src/compiler/diagnosticInformationMap.generated.ts src/compiler/emitter.ts tests/baselines/reference/es6ImportDefaultBinding.errors.txt tests/baselines/reference/es6ImportDefaultBindingFollowedWithNamedImport.errors.txt tests/baselines/reference/es6ImportDefaultBindingFollowedWithNamedImportInEs5.errors.txt tests/baselines/reference/es6ImportDefaultBindingFollowedWithNamespaceBinding.errors.txt tests/baselines/reference/es6ImportDefaultBindingFollowedWithNamespaceBindingInEs5.errors.txt tests/baselines/reference/es6ImportDefaultBindingInEs5.errors.txt
…into exportEquals
…n after the fact "export {x};"
…tExportNameSubstitution
Conflicts: src/compiler/checker.ts src/compiler/emitter.ts src/compiler/types.ts tests/baselines/reference/APISample_compile.js tests/baselines/reference/APISample_linter.js tests/baselines/reference/APISample_transform.js tests/baselines/reference/APISample_watcher.js tests/baselines/reference/es5ExportDefaultClassDeclaration2.js tests/baselines/reference/es5ExportDefaultFunctionDeclaration2.js tests/baselines/reference/es6ExportAllInEs5.js tests/baselines/reference/es6ExportClauseWithoutModuleSpecifierInEs5.js
Merge master into exportEquals
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses feedback on our design for ES6 module support (see #2242). The primary change is that
export defaultandexport =become separate constructs with different semantics:export defaultdeclaration always declares an exported member nameddefaultand is always emitted as an assignment toexports.default. In other words,export defaultconsistently has ES module semantics.export =declaration, which substitutes a different entity to be exported in place of the module itself, is always emitted as an assignment tomodule.exports. It is an error to have other exports in a module that usesexport =. This is the existing TypeScript behavior.export =to export another module or a "module like" entity can be imported using the new ES6 constructs. In particular, the convenient destructuring imports can be used with such modules. The pattern of usingexport =to export another module is common in .d.ts files that provide a CommonJS/AMD view of an internal module (e.g. angular.d.ts).export =to export a non-module entity in place of the module itself must be imported using the existingimport x = require("foo")syntax as is the case today.This approach has several advantages: