-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Unnamed default exports don't work with --t es6 --m commonjs
#5844
Comments
This conditional needs to be updated to emit the temp name if the class is an exported default class when not targeting ES6. Forgot about unnamed classes when adding tests in #5648. While looking at it, it would probably also be a good idea to verify all of the default export results with functions and unnamed function expressions as well... |
same as unnamed function.
|
Actually, I may have misunderstood the expected behavior for TypeScript 1.7 when targeting commonjs with ES6 modules. This also appears to be a problem with named classes that are default exports. $ tsc -v
message TS6029: Version 1.7.3 example.ts // example.ts
export default class Example {
public get() {
return 1;
}
} subExample.ts // subExample.ts
import Example from "./example";
export default class SubExample extends Example {
public get() {
return 3;
}
public foo() {
return 2;
}
} $ tsc -t es6 -m commonjs example.ts subExample.ts example.js // example.js
class Example {
get() {
return 1;
}
}
exports.Example = Example; subExample.js // subExample.js
var example_1 = require("./example");
class SubExample extends example_1.default {
get() {
return 3;
}
foo() {
return 2;
}
}
exports.SubExample = SubExample; When run with node v5:
|
That last bit duplicates #5594 and should be fixed in master. However your original issue still stands. |
Fix #5844 - add many new tests covering named/anonymous default exports
@joeduffy and @nmalaguti can you give |
Thanks all, that was fast! I'll give it a try in the AM. |
This has resolved the issue with default named classes that I was seeing on 1.7 when using ts@next. How does this interact with libraries compiled to commonjs using babel? |
LGTM, works for me. |
not sure i understand the question. |
@mhegazy when babel emits code for es6 imports, it includes a method that looks for "use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
var _example = require("./example");
var _example2 = _interopRequireDefault(_example);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
class SubExample extends _example2.default {
get() {
return 3;
}
foo() {
return 2;
}
}
exports.default = SubExample; If
The variable Is there a plan for how these will interop in the future? |
Even if there isn't right now, as a workaround on your TS modules you can add the |
@nmalaguti i think there is something else going on here. TypeScript compiler will emit the "__esModule", so compileing your // example.ts
var Example = (function () {
function Example() {
}
Example.prototype.get = function () {
return 1;
};
return Example;
})();
Object.defineProperty(exports, "__esModule", { value: true });
exports.default = Example; |
@mhegazy it looks like you targeted es5, not es6 (since the class was compiled into a function). The issue is when targeting es6 and using commonjs modules, the "__esModule" isn't emitted. |
I thought you were passing the es6 output into Babel... |
Sorry for the confusion. The use case would be I write an npm module in TypeScript with ES6 features like generators. I use A consumer of my library npm installs it and wants to use it with babel in order to take advantage of ES6 features. In that case, when they import my module as a default, babel will compile that down in a way that is incompatible since "__esModule" is missing in the TypeScript output. |
Ah! So the issue is that we don't emit our |
i have a fix out for this one: #5907 |
Oh man, I just put out #5908 with almost the same change. |
great minds.. |
@nmalaguti give |
Thanks @mhegazy and @weswigham. I was able to get things working smoothly with |
Hum this was closed but I have the following problem : My TS file :
The compiled result :
How can I remove
|
I wil have to look at the trails-controler definition to be able to help. You are importing it as a default export, so the output is what I would expect. |
@mhegazy thanks.
If this module doesn't export his class the right way, what is the right way to export it ? I'll make a PR on it. |
your import should look like the reason is |
@mhegazy thanks ! That's working (with
With or without |
class Controler {...} |
I'm trying to write a definition for the declare module TrailsController {
export class TrailsController {
app: {
config: any;
sitemap: any;
routes: { path: string, config: {app?: any} }[];
services: any;
};
log: any;
id: any;
__: any;
config: any;
constructor(app: any);
}
}
declare module "trails-controller" {
export = TrailsController;
} |
General questions should be on StackOverflow, Gitter or IRC, but the following works: declare namespace TrailsController {
class TrailsController {
app: {
config: any;
sitemap: any;
routes: { path: string, config: {app?: any} }[];
services: any;
};
log: any;
id: any;
__: any;
config: any;
constructor(app: any);
}
}
declare module "trails-controller" {
const TrailsController: TrailsController.TrailsController;
export = TrailsController;
} |
Compiling the following code:
Using the command line
tsc --t es6 --m commonjs
produces illegal JavaScript:I realize this is a weird combination of switches, however it seems necessary to target current versions of Node.js/V8 that don't yet natively support ES6 modules.
The text was updated successfully, but these errors were encountered: