CODEWITHSUNDEEP
javascriptecmascript-6es6-modules
qarthandso
qarthandso

Reputation: 2188

Understanding ES6 Named Imports

I'm reading through the ES6 import statement on the MDN docs.

I understand generally how it works, but wanting to dive deeper, I'm not understanding one aspect of the syntax.

As stated in the MDN syntax of import, these are all of the different way to import code into the current module/scope:

import defaultExport from "module-name";
import * as name from "module-name";
import { export } from "module-name";
import { export as alias } from "module-name";
import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";
import { export1 , export2 as alias2 , [...] } from "module-name";
import defaultExport, { export [ , [...] ] } from "module-name";
import defaultExport, * as name from "module-name";
import "module-name";
var promise = import("module-name");

What I'm trying to understand is the difference between these two lines:

import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";

Wouldn't both of those be exactly the same? We're not importing a default export, therefore we have to be importing named exports.

Why are they two separate syntax definitions?

And why does the second one have this:

from "module-name/path/to/specific/un-exported/file";

Upvotes: 8

Views: 2716

Answers (1)

artem
artem

Reputation: 51809

import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";

Why are they two separate syntax definitions?

Probably just to illustrate the point that absolute module name can also contain a path.

Then, "module-name" will be resolved according to usual module resolution rules, and then foo and bar will be imported from some file contained within that module.

That way, you can get access to something which is not exported from the main file of the module.

However, many module authors consider that only exports from the module main file constitute the public API. Everything else, including file names and paths, is an implementation detail which may change in unpredictable and incompatible way with each release.

Upvotes: 5

Related Questions