Support ES export * as ns from form

[mhegazy]

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"

[vilicvane]

👍

[nevir]

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

[aluanhaddad]

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]

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]

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]

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

[nevir]

You can do: export { default as React, PureComponent, PropTypes, } from 'react'

…

On Wed, May 10, 2017, 11:32 mikew ***@***.***> wrote: Even more strange that export { connect } from 'react-redux' works. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4813 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAChnZzvzQc10WXj9VkLM1HGl7B_D5Ulks5r4gLCgaJpZM4F-BqL> .

[mikew]

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

[aluanhaddad]

@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]

#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

[weswigham]

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

[Jessidhia]

export * as ns from "foo" was merged and is now officially part of the language tc39/ecma262#1174

It probably should be preserved instead of downleveled in esnext / es2020 emits.

---

Tangentially, this syntax is useful because of a bug in webpack 4 (fixed in webpack 5). It treats export * as ns from ... differently from the downlevel form, and is no longer capable of "tree shaking" if it's written in the downlevel form.

[DanielRosenwasser]

Changed the title since there is currently no export default version of this.

[Jessidhia]

It's still mis-titled because it's no longer "proposed"; it is already in the spec 😉

[ExE-Boss]

I’ve now opened #35010 for the export default from form.

[DanielRosenwasser]

Thanks @Kingwl!

[katis]

Previously I liked using TS namespaces and declaration merging for creating FP-style modules, without needing the MyModule.T convention:

export type Foobar = { }

export namespace Foobar {
  export function doStuff(foobar: Foobar) { }
}

import { Foobar } from './Foobar'

Foobar.doStuff(fb)

Namespaces are not really the way to go any more, babel doesn't support them, they probably aren't tree-shakeable etc. But I was hoping that the export * as ns syntax could be used as a replacement, like this:

export type Foobar = import('./Foobar').Foobar

// Or:
// export type { Foobar } from './Foobar'

export * as Foobar from './Foobar'

This seems to pass the nightly compiler, but the compiler only knows that Foobar is re-exported as a type, not a value. It would be great if the compiler could merge them into a combined value & type like with namespaces.

[rbuckton]

@katis: I filed #36792 with the content of your comment above.

I'm closing this issue as it was fixed in #34903.