What does a sub-path mean in the context of import statements?

Question

Suppose I have a statement like this:

import * as bar from 'foo/bar';

I have a few questions:

• What does the /bar bit mean?
• Is there a sepcific (google-able) term for this?
• Does this provide efficiency gains (reducing module bloat)?
• How can I bundle a common-js module (ideally with Rollup) on NPM and support this syntax?

Answer 1

Breaking it down:

Firstly to provide context to your first and second question, let's go a bit further and break down all the parts of that statement:

import * as quux from 'foo/bar';

Note: The first bar instance in your example has been intentionally changed to quux to disambiguate the following points.

1. Collectively it is referred to as an Import Statement, or more specifically; an Import Declaration as defined in the ECMA-262 Imports Syntax Specification.

2. The import part is referred to as the Import Keyword.

3. The * as quux part is referred to as a NameSpace Import.

   • The asterisk * indicates that all exported bindings in bar will be imported to a newly created namespace object called quux. The resultant effect is that the quux object will hold all the exported members from bar.
   • The quux part of that is referred to as the Imported Binding and, as previously mentioned, it's used as the name for the newly created namespace object.

4. The from 'foo/bar' part is referred to as the From Clause.

   • The foo/bar part is a String Literal and is referred to as the Module Specifier... it's simply a filepath.

---

Answers to your specific questions:

1. What does the /bar bit mean?

   It's part of the Module Specifier which is part of the From Clause. It is simply a reference to the name of the file whose exported member(s) will be imported from. In this example its exported member(s) will be imported into a new namespace object called quux.

   With regards to what is that actual "part" called; ECMA-262 doesn't provide a specific reference/name for it, however, I refer to that part as the filename; (i.e. the filename in the filepath of the module to import).

   As far as I know, /bar may or may not need to include a file extension (i.e. /bar.js). Again there's nothing in the ECMA-262 Imports Syntax that enforces this. ECMAScript only defines the syntax for modules and not the specific mechanism(s) for loading them. So the requirement for with or without a .js suffix may vary per implementation. For example:

   • In Apple's latest Safari browser built upon WebKit which runs on iOS the inclusion of the .js suffix is necessary.
   • In Modules docs for Node v8.10.0 they do include the .js file extension for imported files in their examples. Note: As ES6 Modules currently have a Stability Index 2 this could change.

2. Is there a specific (google-able) term for this?

   Not per se, as ECMA hasn't named it specifically. You could try googling some of the terminology/nomenclature that I've previously mentioned.

3. Does this provide efficiency gains (reducing module bloat)?

   I'm not sure I fully understand what you mean by "module bloat". However, If you mean will it result in less modules in application code? I think not, it's more likely result in an increased usage of modules.

   Efficiency gains will be had from there being native ES6 Module support. Native support by it's very nature can bring speed/performance increases. Other benefits of ES6 Modules are:

   • ES6 Modules are statically analyzable which allows dead/unused code elimination via a process named Tree Shaking. More info here and here . So, if that's what you mean by the term "module bloat" - then yes; unused/dead code will be removed by tools that perform Tree Shaking.

     Caveat; I'm not 100% certain whether tools that perform Tree Shaking are capable of removing dead code when using the wildcard/asterisk (*) in a NameSpace Import. It MAY be necessary to import specific member(s) that you'll use instead, i.e.

       import { foo, bar, quux } from './foo/bar.js';
     

   • It's an official ECMAScript standard.

   • The example that you gave included a NameSpace Import, so there's another benefit - it will help to avoid namespace collisions.

   • More benefits are mentioned here.

4. How can I bundle a common-js module (ideally with Rollup) on NPM and support this syntax?

   Rollup works with a plugin named @rollup/plugin-commonjs which will convert CommonJS modules to ES6, so they can be included in a Rollup bundle.