Import wildcards

Maël Nison nison.mael at gmail.com
Sun May 29 20:01:16 UTC 2016


I might be wrong, but the export * from '...'
<http://www.ecma-international.org/ecma-262/6.0/#sec-exports> syntax seems
to re-export every symbol from a given module, effectively exporting
indirectly those symbols (since you need to parse the imported module to
know which symbols will be available). This syntax is quite valuable for
configuration files, since you can "export *" from a base configuration,
then overwrite specific symbols by using the usual "export MY_SYMBOL"
syntax.

Le sam. 28 mai 2016 à 17:06, Matthew Robb <matthewwrobb at gmail.com> a écrit :

> 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" <nison.mael at gmail.com> 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 <zenparsing at gmail.com> 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 <nison.mael at gmail.com>
>>> 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 mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160529/de9406c1/attachment.html>


More information about the es-discuss mailing list