Discuss
  • Import wildcards

Import wildcards

# Maël Nison (8 years ago)

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 ?

# Kevin Smith (8 years ago)

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';
# Maël Nison (8 years ago)

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 :

# Matthew Robb (8 years ago)

Not exactly. To export a binding it must be declared in scope somewhere which means it's statically analyzable within a given file.

# Maël Nison (8 years ago)

I might be wrong, but the export * from '...' 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 :

# Logan Smyth (8 years ago)

I think my biggest issue with this is that it seems like a solution in search of a problem. I can kind of see that you might end up with a setup where common property prefixes are common in the case of config files where you want many config options in one file. However, in the vast majority of JS code, modules, scoping, and objects exist to provide a namespacing already, making common prefixes extra work with little gain.

Having an import syntax aimed at allowing prefix-based imports solves what could likely be solved more cleanly using the existing syntax combine with changes to the structure of the data being exported.

You could for instance have specific sub-files for individual config namespaces.

import * as API from 'config/api';
API.USERNAME;
API.TOKEN;

or if you want to keep everything in the same file, why not use an object to create the namespace,

export const API = {
    USERNAME: '',
    TOKEN: '',
};

with

import {API} from 'config';
API.USERNAME;
API.TOKEN;
# Matthew Robb (8 years ago)

On Sun, May 29, 2016 at 4:01 PM, Maël Nison <nison.mael at gmail.com> wrote:

effectively exporting indirectly those symbols (since you need to parse the imported module to know which symbols will be available).

​The difference with export * from '...'; syntax is that it doesn't indirectly introduce named bindings into a scope. If you want a named binding you must explicitly declare it. The reasons are numerous but a goal is to keep as much of the module syntax statically analyzable.​ Using the import * as dotdotdot from '...'; syntax skirts this a bit and is in place for usages precisely like your own.

  • Matthew Robb