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

Support proposed ES `export from` forms #4813

Open
mhegazy opened this issue Sep 15, 2015 · 26 comments

Comments

Projects
None yet
@mhegazy
Copy link

commented Sep 15, 2015

The ES7 proposal is available at: https://github.com/leebyron/ecmascript-more-export-from

The additions include:

reexporting default:

// proposed:
export v from "mod";

// symmetric to:
import v from "mod";
export {v};

reexporting as sub-module:

// proposed:
export * as ns from "mod";

// symmetric to:
import * as ns from "mod";
export {ns};

also allowing combining

// proposed
export v, {x, y as w} from "mod"
// symmetric to
import v, {x, y as w} from "mod"
As well as

// proposed
export v, * as ns from "mod"
// symmetric to
import v, * as ns from "mod"

@vladima vladima changed the title Support porposed ES7 `export form` forms Support proposed ES7 `export form` forms Sep 15, 2015

@vladima vladima changed the title Support proposed ES7 `export form` forms Support proposed ES7 `export from` forms Sep 15, 2015

@vilic

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2015

👍

@mhegazy mhegazy changed the title Support proposed ES7 `export from` forms Support proposed ES.Next `export from` forms Feb 4, 2016

@mhegazy mhegazy added ES Next and removed ES7 labels Feb 4, 2016

@mhegazy mhegazy changed the title Support proposed ES.Next `export from` forms Support proposed ES `export from` forms Feb 4, 2016

@nevir

This comment has been minimized.

Copy link

commented Jul 25, 2016

This would be incredibly helpful for supporting intellisense for JavaScript projects in VS Code; export * as foo from './foo'; seems pretty widely used

@aluanhaddad

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2016

At first I thought this (the ECMAScript proposal) was a bad idea because the preponderance of existing export forms is a source of confusion for newcomers. However, I've come around to the idea that the asymmetry between the import and export forms is actually a source of confusion in itself so adding this would be beneficial.

@jetpacmonkey

This comment has been minimized.

Copy link

commented May 1, 2017

Is there any chance of this being added sometime soon? I've been using this feature in my codebase with the stage-1 babel preset, and was hoping to start using typescript to get gradually get some static typechecking, but typescript throws a bunch of errors every time it comes across export x from './y';

@mikew

This comment has been minimized.

Copy link

commented May 10, 2017

Our team's projects usually has a common file for developers to import common things from, without having to worry about where they come from:

import {
  React,
  PropTypes,
  PureComponent,
  Button,
  connect,
} from './common'

Without export from, this common file will double in size and have needless duplication and some lines that can be confusing to newcomers.

// This ...
export React, {
  PureComponent,
  PropTypes,
} from 'react'

// ... becomes ...
import * as _React from 'react'
export const React = _React
export const PropTypes = _React.PropTypes
export const PureComponent = _React.PureComponent
@mikew

This comment has been minimized.

Copy link

commented May 10, 2017

Even more strange that export { connect } from 'react-redux' works.

@nevir

This comment has been minimized.

Copy link

commented May 10, 2017

@mikew

This comment has been minimized.

Copy link

commented May 10, 2017

Almost, except then it's module "@types/react/index" has no exported member 'default'.

@aluanhaddad

This comment has been minimized.

Copy link
Contributor

commented May 11, 2017

@mikew That is true but the same issue would apply to the proposed

export React, {
  PureComponent,
  PropTypes,
} from 'react';

The default issue is a complex issue stemming from a convoluted set of incompatibilities and disparate assumptions made by standards, languages, environments, loaders, bundlers, runtimes, and transpilers.

However, it is entirely orthogonal to this proposal.

If you can write

import React from 'react';

and it works at runtime, set the --allowSyntheticDefaultImports flag.

@mjbvz

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2017

#9906 tracked the proposed export default from ( https://github.com/tc39/proposal-export-default-from ) and was marked as a duplicate of this

Adding this comment to make sure the request for supporting export default from isn't potentially overlooked as part of this issue

@glixlur

This comment has been minimized.

Copy link

commented Aug 17, 2017

Is this on the roadmap or we have to wait until the proposal reaches a certain stage?

@kitsonk

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2017

Is this on the roadmap or we have to wait until the proposal reaches a certain stage?

IIRC, they tend to be taken on a case by case basis. Pre Stage 3 tend to get implemented under a flag, and only if they are important enough. Stage 3s tend to get implemented without flags.

@MitchStephan

This comment has been minimized.

Copy link

commented Jan 9, 2018

Is this still not supported? Or is there a setting I am missing in jsconfig?

@plantain-00

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2018

This spec has been withdrawn in favor of the equivalent micro-proposals: export ns from and export default from.

https://github.com/tc39/proposal-export-default-from
https://github.com/tc39/proposal-export-ns-from
They are both stage 1 now, usually, typescript will not support them until they are in stage 3.

@lukescott

This comment has been minimized.

Copy link

commented Mar 1, 2018

proposal-export-ns-from is being PR'd into the language spec tc39/ecma262#1005, assuming consensus, which makes it official. I don't understanding the how/why it's bypassing the staging process, but apparently it is.

Any plans to get this implemented into TypeScript?

@mhegazy

This comment has been minimized.

Copy link
Author

commented Mar 1, 2018

Once the proposal makes it to stage 3, we will add support for it.

@lukescott

This comment has been minimized.

Copy link

commented Mar 1, 2018

OK, so if it's not listed in https://github.com/tc39/proposals at all (source of truth for stages), yet it's being PR'd into the language spec (tc39/ecma262#1005) pending consensus (conceptually, but not technically stage 4), what stage is it right now?

Sorry, I'm just not sure what this is considered, and how this fits into the stage 3 policy. Trying to get some understanding of what's going on.

There's also babel/proposals#16, which marks it as "Needs Consensus PR", which before today was listed as "Stage 4", which I'm told is semi-sorta the same thing, but not really unless it's merged.

@mhegazy

This comment has been minimized.

Copy link
Author

commented Mar 1, 2018

@bterlson what stage is this proposal in at the moment?

@rclai

This comment has been minimized.

Copy link

commented Apr 16, 2018

I'd like to add that this form should also be supported if not already covered.

export { default } from 'some-module'

This is the form that create-react-app apps accepts.

@mhegazy

This comment has been minimized.

Copy link
Author

commented Apr 16, 2018

@rclai this should be already supported. ‘export default form “mod”’ is not.

@rclai

This comment has been minimized.

Copy link

commented Apr 16, 2018

I have a

// SomeComponent.js 
export default function SomeComponent() {
  return null
}

// index.js
export { default } from './SomeComponent'

When I import this from another place

import SomeComponent from 'components/SomeComponents'

The autocomplete works, but Cmd clicking on the import declaration variable or path doesn't take me to the SomeComponent.js and peeking doesn't work on it.

Am I missing some config or is this a separate issue?

@rclai

This comment has been minimized.

Copy link

commented Apr 16, 2018

My jsconfig.js

{
  "compilerOptions": {
    "target": "es2015",
    "baseUrl": "./src",
    "paths": {
      "components/*": ["./components/**/*"]
    }
  }
}

@mhegazy

This comment has been minimized.

Copy link
Author

commented Apr 16, 2018

Sorry my bad. I read it as ‘export { default as foo} from “mod”’.

Yes exporting the default is not supported yet

wordofchristian added a commit to reakit/reakit that referenced this issue Jul 14, 2018

@wordofchristian wordofchristian referenced this issue Jul 14, 2018

Merged

Typescript #146

10 of 10 tasks complete
@aMoniker

This comment has been minimized.

Copy link

commented Oct 31, 2018

Any update on when this will make it in?

@kitsonk

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

@aMoniker the proposal was broken into two. The export * as ns from "mod" is covered in a consensus PR at: tc39/ecma262#1174 which still has not made it into the language specification. Until that happens, TypeScript won't consider implementing it, though it is already shipping in most browsers.

The other part of the syntax, export v from "mod" is still a Stage 1 proposal: https://github.com/tc39/proposal-export-default-from and the TypeScript team won't consider implementing it until it reaches Stage 3 (or is added also via a consensus PR).

@weswigham

This comment has been minimized.

Copy link
Member

commented May 22, 2019

export * as ns from "foo" was shipped in v8 7.2, meaning current node and chrome can technically support it in their modules implementations - the downlevel isn't hard (just rewrite into

import * as ns from "foo";
export { ns }

and feed down the transformer pipeline). This does imply a new module target that doesn't downlevel it, though, which means a bump of the exnext module and the addition of es2019 modules - the exact timing is a little muddy, since AFAIK it's shipped in v8 even though the proposal is still stage 1.

cc @RyanCavanaugh so we're aware

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.