Not exactly. To export a binding it must be declared in scope somewhere which means it's statically analyzable within a given file. On May 28, 2016 9:49 AM, "Maël Nison" <[email protected]> wrote:
> I see, but unless I'm mistaken, the same issue occurs with the export * > from '...' syntax, right ? > > Le ven. 27 mai 2016 à 16:06, Kevin Smith <[email protected]> a écrit : > >> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
