Import wildcards

Kevin Smith zenparsing at
Fri May 27 14:06:03 UTC 2016

With this syntax, you would not be able to statically tell whether a
particular variable name (e.g. API_FOO) is bound to a module import,
without also analyzing the dependencies (and perhaps their dependencies).
These considerations killed the original "import all" syntax.  (`import *
from 'foobar'`);

If repitition is an issue, use the namespace import form.

    import * as constants from 'config';

On Fri, May 27, 2016 at 10:00 AM Maël Nison <nison.mael at> wrote:

> Hi,
> In about every project I have, I write a file or two with this form:
>     export let API_USERNAME = `name`
>     export let API_TOKEN = `token`
>     // etc
> Most of the time, when I need one of those variables somewhere, I also
> need the other. It might be burdensome, since I end up with something
> similar to this:
>     import { API_USERNAME } from 'config';
>     import { API_TOKEN } from 'config';
>     // etc
> Of course, I can import all of these token in a single line, but it
> doesn't help readability when there is a lot of entries (we all know that
> configuration files always end up with a fair number of variables - and
> let's not talk about parsers and similar). Plus, it's not very fun to
> explicitely write all these names when I just want to tell the engine that
> I will need everything similar, pretty please.
> Now as for the request: what would you think about adding a new syntax
> -nothing too fancy- to import all the symbols that match a *static *pattern?
> In the spirit of the `export * from ...` syntax, I feel like the following
> could be interesting:
>     import { API_* } from 'config';
> As for the bad part: there really isn't, actually. This syntax is familiar
> with every developer that used globing before, and gives just enough
> insight to someone looking at the source code to understand that a variable
> named `API_SOMETHING` has been imported from a parent module. Linters would
> also be able to help in this regard, since they would just have to
> blacklist declaring variables that would conflict with an import prefix.
> Any thoughts ?
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list