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