archives

« Bugzilla Issues Index

#3106 — import into namespace syntax


The syntax for importing into a namespace is changing from

module fs from "fs";

to

import * as fs from "fs";

It should also be possible to combine `* as fs` with the comma syntax, e.g.:

import * as fs, { readFile, unlink } from "fs";

Dave


And default import too I assume?


I've added the: import * as fs from "fs";
syntax in the Rev28 draft.

WRT to Erik's point, I dislike what we get if we try to combine this with the default import syntax. I wonder if we really need it. Assuming that a binding for "default" is included in module namespace objects (is it?) somebody could just say:

import * as fs from "fs";
const defaultFS = fs.default;


fixed in rev28 editor's draft

The revised grammar is:

ImportDeclaration :
'import' ImportClause FromClause ';'
'import' ModuleSpecifier ';'


ImportClause :
ImportedDefaultBinding
NameSpaceImport
NamedImports
ImportedDefaultBinding ',' NameSpaceImport
ImportedDefaultBinding ',' NamedImports
NameSpaceImport ',' NamedImports

ImportedDefaultBinding :
ImportedBinding

NameSpaceImport :
'*' 'as' ImportedBinding


Argh, I was wrong in the bug description about which cases of mixing to allow. The comma syntax distinguishes two positions: the left allows you to talk about the default export, and the right allows you to talk about the named exports. So you should be able to say

import $ from "jquery";
import * as jQuery from "jquery";
import { ajax } from "jquery";
import $, * as jQuery from "jquery";
import $, { ajax } from "jquery";

But we shouldn't allow the case I mentioned in the description, because that mixes up what the two sides of the comma mean. And it's a sufficiently rare case that it doesn't need single-line syntax.

Luckily this only means there's one bogus case in the grammar: we need to drop the

NameSpaceImports ',' NamedImports

production from the ImportClause non-terminal. Sorry for the mistake in the bug description.

Dave


We should either support all possible combination or no combinations.

Picking a subset is only going to lead to confusion.

I believe (based on years of using ES modules as they have evolved) that any combination of these are sufficiently rare that we do not need to support it in ES6.

If it turns out that there is a need we can easily extend the grammar in future spec versions.


fixed in rev28