-
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
ES6 Modules #2242
Comments
Babel handles mangling default exports with named exports just fine in both AMD and CommonJS. This (amongst other thigs) allows for some nice ways to create default instances of classes, like export class Logger {
// stuff
}
export default new Logger(defaultArgs); which results in the following CommonJS code: var Logger = exports.Logger = function Logger() {
_classCallCheck(this, Logger);
};
exports["default"] = new Logger(defaultArgs);
exports.__esModule = true; When importing this as import defaultLogger, {Logger} from './log'; it generates the following: var _interopRequire = function (obj) { return obj && obj.__esModule ? obj["default"] : obj; };
var _log = require("./log");
var defaultLogger = _interopRequire(_log);
var Logger = _log.Logger; The trick here is the |
Oh, and as a side-note, given that typescript typically has metadata about everything, the |
👍
I suggest the addendum: "TypeScript's original internal and external module constructs are deprecated and may not be supported in future versions". (With the aim of discouraging multiple ways of doing the same thing.) Also I couldn't find anything that says what happens when a module is imported and used in a type-only position. I would expect the down-level emit to omit the |
@Alxandr It's a nifty scheme, but one issue is that if |
@ahejlsberg babel actually deals with this by special casing files that only export a default to use |
It's (IMHO at least) better than disallowing default and named exports at the same time. |
@ahejlsberg I hear what you are saying about wanting to get everyone on board with the One True Module Format. I have that desire as well. However, I think I also share some of @Alxandr’s concern that if TypeScript isn’t following the rules of that module format more closely that it’s going to cause problems as the “standard” ES6 module format does lots of non-standard things in TypeScript emitting to ES5. In particular I definitely want people to be to experience the benefits of being able to have circular dependencies on modules with default values, which is currently not possible with the way AMD (and, in some ways, CJS) modules work. This is a fairly important feature when doing things like creating data models that have circular relations to other types, without either using an intermediate registry to retrieve types, or hanging values that should be defaults off of properties (the I also understand and share the concern about emitting TS modules for down-level consumers that won’t know this One Weird Trick from Babel to support ES6 modules. I feel like continuing to support Please let me know your thoughts on this if you have a moment, I’d like to have some holes poked in my thinking here. Thanks! |
@Alxandr I think your suggestion has a lot of merit. Let me summarize what I think we would do. If a module has only a default export, emit an assignment to // TypeScript code
export default function foo() { }
// Code emitted for CommonJS
function foo() { }
module.exports = foo; Otherwise, emit everything as assignments to // TypeScript code
export function foo() { }
export function bar() { }
export default { foo, bar };
// Code emitted for CommonJS
function foo() { }
exports.foo = foo;
function bar() { }
exports.bar = bar;
exports.default = { foo: foo, bar: bar };
exports.__esmodule = true; On the import side, include an // TypeScript code
import d, { foo } from "./foobar";
d.foo();
foo();
// Code emitted for CommonJS
var _a = require("./foobar"), d = _a && _a.__esmodule ? _a.default : _a;
d.foo();
_a.foo(); It's not quite as pretty as what is emitted now, but I think it is worth it to get support for full ES6 module semantics down-level (as well as interop with modules emitted by Babel). For an original import-equals declaration, we would give an error if the imported module has both regular exports and a default export (i.e. if it is an ES6 module). Such modules would only be importable using the new ES6 syntax. @csnover With this proposal you'd be able to have circular dependencies between modules with default exports as long as the modules have at least one regular export as well (which could just be a dummy member). |
@ahejlsberg wouldn't it be possible to skip the fancy emit given metadata? I mean, typescript has typeinformation about everything (which is sort of the idea, right)? So if we know that the module being imported, we should know the format it exports at, right? |
Is it better to give an error for using import-equals to import an es6 module? Or is it better to emit an import-equals declaration in the same way as a default import? We could emit: import d = require("./foobar"); as var _a = require("./foobar"), d = _a && _a.__esModule ? _a.default : _a; |
Also, to make circular references work, don't you have to access the default member late? So instead of assigning the default to d eagerly, a call to |
@Alxandr Yes, I think it would work to have the following rules:
We would lose the ability to dynamically adapt on import based on the I suppose we'd still want to emit the @JsonFreeman I think we have two choices for import-equals with an ES6 (mixed) module. Either say it is an error (there's no backwards compatibility to worry about) or say that you get the module object with a set of properties including one named Regarding circular references, you're right, we'd want to rewrite references to the default import in the same way we'd do with any other import. Which in turn means we don't want the dynamic |
In terms of backward compatibility, importing code that previously did not error, would now error if the exporting module suddenly starts exporting other stuff besides its default export. But I guess the argument is, in that case it's better to get an error than to suddenly get different semantics. So I guess in that sense, there is no real break of backward compatibility. @ahejlsberg, you mentioned skipping the dynamic check on the import side. I agree it's nicer to not have it, but I have one question. Does this mean that the following assigns directly to module.exports? class C { }
export { C as default }; |
What about this? Would this assign directly to module.exports?: // In a file A.ts
export default class { };
// In a file B.ts
export * from "A"; // Does this assign directly to module.exports? Or just an empty namespace? |
@JsonFreeman Yes, your class first example would assign directly to export { C as default }; is precisely equivalent to writing export default C; Regarding your second example, an |
Great, thanks. I believe this design is consistent and reasonable. |
Yes, the spec specifically allows the identifier following https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports |
@jbondc I don't think the first export there is legal. At least babel throws on the |
@jbondc From using ES6 with babel for a good while, I've almost never used Another point that pooped up from your question though is exports inside of internal modules. How will that be handled? Do I do the following? export module Foo {
export class Bar {}
} or is the following enough module Foo {
export class Bar {}
} And how do I import it? import { Foo } from './file';
new Foo.Bar(); Or will internal modules get removed down the line, as they were from the module draft for ES6? |
@Alxandr @jbondc A TypeScript internal module is really no different than other declarable entities such as classes, functions, and enums when it comes external modules. For example, given this external module that exports an internal module export module Foo {
export class Bar { }
} you can import as follows import { Foo } from "./mod";
new Foo.Bar(); However, as you've observed, ES6 import and export declarations don't allow you to "dot into" the substructure of internal modules (understandable, as they aren't part of ES6). So, for example, the following is not allowed: import { Foo.Bar as Bar } from "./mod"; // Error, qualified name not allowed You would have to do it in two steps by adding a TypeScript import-equals: import { Foo } from "./mod";
import Bar = Foo.Bar; In general I don't think it will be common to mix the two, nor is it clear that we want to encourage it. |
Having spent a total of several hours trying to come up with a new ES6 style syntax to apply The import {FileReader} from "FileSystem"; as expected, would import the export (let's say in this case a class) import FileReader from "FileSystem"; would unexpectedly import the default export from the module and assign it the identifier Apart from being a huge pitfall for human error and confusion, I also think it "abuses" the import "FileSystem" as FS; where the |
@rotemdan It's popped up on es and possibly other places: Another part that's been mentioned is: There seemed to be a preference for (b) |
@Alxandr @JsonFreeman Having given some more thought to whether metadata should guide the code generation for ES6 import declarations, I now think that it shouldn't. The problem with the metadata guided approach is that it only works when modules are compiled together. For example, say that module "a" is a default export only module and that "b" imports the default export of "a". Now say that "a" adds a regular export, thus becoming a mixed module. "b" now needs to be recompiled because the code to import the default export of "a" is different. For "b" to be unaffected by such changes in "a" we need to include dynamic Also, only by including @csnover The upshot of this is that imports of default exports will always be evaluated eagerly (as they are now), and I don't see any way in which we could make circular references between default exports work in CommonJS or AMD. |
Sorry for bringing this up. import express from 'express'; and import express = require('express'); Is this correct or did I get the wrong idea? To be more concrete, when I use this typings file: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/express/express.d.ts I'd like to be able to write Thanks. |
@miguelcobain it sounds like what you actually want to do is compile with |
oh oh oh 🙋 I know the answer : no 🙅 🌹 |
@RyanCavanaugh that option was what I was looking for. Many thanks! |
Hi!
//file tsconfig.json
links: |
Sorry - alm issue pls ignore
|
@teyc That looks like an alm error. Feel free to create an issue there https://github.com/alm-tools/alm/issues but you will have to provide more information / reproduction steps 🌹 |
This issue describes TypeScript's support for ECMAScript 6 modules as implemented in #1983, #2197, and #2460.
TypeScript 1.5 supports ECMAScript 6 (ES6) modules. ES6 modules are effectively TypeScript external modules with a new syntax: ES6 modules are separately loaded source files that possibly import other modules and provide a number of externally accessible exports. ES6 modules feature several new export and import declarations. It is recommended that TypeScript libraries and applications be updated to use the new syntax, but this is not a requirement. The new ES6 module syntax coexists with TypeScript's original internal and external module constructs and the constructs can be mixed and matched at will.
In TypeScript 1.5, a source file is considered an external module if it contains at least one of the following:
export
modifier.export = Point
.import Math = require("math")
.An external module has a set of exports that are specified using various forms of export declarations. Those exports can be imported into local name bindings in other modules using various forms of import declarations.
An external module may designate a default export, which is an export with the reserved name
default
. A number of short-hand export and import declaration constructs exist to facilitate easy export and import of the default entity.For backwards compatibility with CommonJS and AMD style modules, TypeScript also supports export-equals declarations of the form
export = Point
. Unlike default export declarations, which are just shorthand for an export nameddefault
, export-equals declarations designate an entity to be exported in place of the actual module.As ES6 modules gain adoption, TypeScript's original export-equals and import-equals declarations are expected to become legacy.
Export Declarations
When a declaration specifies an
export
modifier, each declared name is exported from the containing module exactly as is the case with original TypeScript external modules. For example:Module members can also be exported using separate export declarations, and such declarations can specify different names for exports using
as
clauses. For example:An export declaration exports all meanings of a name. For example:
Re-exporting
An export declaration that specifies a
from
clause is a re-export. A re-export copies the exports of a given module to the current module without introducing local names.An
export *
declaration can be used to re-export all exports of another module. This is useful for creating modules that aggregate the exports of several other modules.An
export *
doesn't re-export default exports or exports with names that are already exported from the current module. For example, thetransform
export in the module above hides anytransform
export in the re-exported modules.Default Export
An export default declaration specifies an expression that becomes the default export of a module:
An export default declaration is just a short-hand way of exporting an entity with the name
default
. For example, the module above could instead be written:When an export default specifies a single identifier, all meanings of that identifier are exported:
An export default declaration can directly declare and export a function or class. The function or class can optionally be named so it can be referenced in the implementing module, but the exported name is always
default
.The following exports an unnamed function with the exported name
default
:The following exports a class with the local name
Greeter
and the exported namedefault
:Import Declarations
The exports of a module are imported using import declarations. Import declarations can optionally use
as
clauses to specify different local names for the imports. For example:As an alternative to individual imports, a namespace import can be used to import an entire module:
Default Import
The default export of a module is particularly easy to import:
The above is exactly equivalent to importing the export named
default
:It is possible to import both the default export and named exports in a single import declaration:
Bare Import
A "bare import" can be used to import a module only for its side-effects. Such an import creates no local name bindings.
CommonJS and AMD Code Generation
TypeScript supports down-level compilation of external modules using the new ES6 syntax.
-t ES3
or-t ES5
a module format must be chosen using-m CommonJS
or-m AMD
.-t ES6
the module format is implicitly assumed to be ECMAScript 6 and the compiler simply emits the original code with type annotations removed.When compiling down-level for CommonJS or AMD, named exports are emitted as properties on the loader supplied
exports
instance. This includes default exports which are emitted as assignments toexports.default
.Below are some examples of external modules and the code emitted for CommonJS and AMD.
A module with named exports:
A module with a default export:
A module with re-exports:
Importing a module:
Note that destructuring import declarations are rewritten to property accesses on the imported module object. This ensures that exported members can circularly reference each other. For example:
This generates the following code when compiled for CommonJS:
Interoperabitility
An existing external module that doesn't use
export =
is already ES6 compliant and can be imported using the new ES6 constructs with no additional work.An external module that uses
export =
to export another module or a "module like" entity can also 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).A module that uses
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.The text was updated successfully, but these errors were encountered: