Skip to content
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

Missing default when re-exporting with export = #8840

Closed
demurgos opened this issue May 26, 2016 · 7 comments
Closed

Missing default when re-exporting with export = #8840

demurgos opened this issue May 26, 2016 · 7 comments
Labels
External Relates to another program, environment, or user action which we cannot control. Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@demurgos
Copy link

demurgos commented May 26, 2016

TypeScript Version:

nightly (1.9.0-dev.20160518-1.0)

Code

// export-default.ts
export let foo = "bar";
export default foo;

// re-export.ts
import alias = require("./export-default");
export = alias;

// main.ts
import foo from "./re-export";
console.log(foo);

Expected behavior:
This project should compile and executing main.ts should output "bar".

Actual behavior:
The following compilation error occurs:

main.ts(1,8): error TS1192: Module '"D:/projects/expor-default/re-export"' has no default export.

Comment
This issue prevents typings from exposing default exports ( original typings issue).

The syntax in re-export.ts is used as a workaround for TS preventing the augmentation of module-definitions re-exported with export * from "export-default" (see this issue and this comment).

@demurgos demurgos changed the title Export default when re-exporting with export = Missing default when re-exporting with export = May 26, 2016
@blakeembrey
Copy link
Contributor

@mhegazy this is breaking a few people using default exports with Typings (see typings/typings#525).

@weswigham
Copy link
Member

If I remember correctly, this is currently because we treat export = importedNamespace exactly as export * from "imported-module"; which, per spec, doesn't reexport default. This would be another point where the two syntaxes would diverge.

@blakeembrey
Copy link
Contributor

Thanks @weswigham. In that case, I switched to the import = export = syntax because of a different TypeScript issue - originally I used export * here which is perfectly fine, except you can't augment things from export *. It seems like an odd limitation, since can't you realistically augment export * properties in JavaScript? (More information in typings/registry#270).

@mhegazy
Copy link
Contributor

mhegazy commented Jun 7, 2016

I highly recommend not mixing up export = patterns in this way. you should be using export default and export * from "mod" instead.
as @weswigham noted, this is currently working as intended. the module re-export.ts really does not have a default export.

@mhegazy mhegazy closed this as completed Jun 7, 2016
@mhegazy mhegazy added External Relates to another program, environment, or user action which we cannot control. Working as Intended The behavior described is the intended behavior; this is not a bug labels Jun 7, 2016
@blakeembrey
Copy link
Contributor

blakeembrey commented Jun 7, 2016

@mhegazy That means Typings can not work and will never work.

@blakeembrey
Copy link
Contributor

If you look at the message above, that's how it used to work - but it broke people who wanted to augment modules.

@unional
Copy link
Contributor

unional commented Jun 9, 2016

@mhegazy , IMO, I agree that the interop between ES2015/commonjs is hairy. Until a standard spec is derived we (the consumer) should avoid doing interop and use the module as it intended to be.

But currently it is a necessity as more and more people adapt to ES2015 thanks to Babel and TypeScript. I think we all appreciate the effort the team put in to make it a reality.

As for the interop, it has to be complete. As now commonjs -> ES2015 works (except #7398), and ES2015 -> commonjs also possible:

import alias = require("./export-default");
export = alias;

the solution has to be complete and cannot leave out the export default part.
Currently this is a blocking issue. Please reconsider.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
External Relates to another program, environment, or user action which we cannot control. Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants