feat(examples): add example for context modules + code split via import()

[TheLarkInn]

What kind of change does this PR introduce?
Adds a ContextModule+Code Splitting+Native import() example

Did you add tests for your changes?
N/A

[Jessidhia]

It'd be better to use an export default and log template.default instead (or destructure { default: template }).

Not requiring the destructuring might actually be a spec violation, even when importing a commonjs module. CommonJS exports should always be mapped to a default export.

I will look into the commonjs module situation once my PR for spec: true commonjs modules is merged to babel, to have an easier migration path from babel modules + webpack1 to webpack2 modules.

[TheLarkInn]

Sounds good. I'll take a look at this. I know Uglify crapped out on this example because of the async await also.

[sokra]

Not requiring the destructuring might actually be a spec violation, even when importing a commonjs module. CommonJS exports should always be mapped to a default export.

Do you have a reference/link to the spec which defines the commonjs interop behavior?

[Jessidhia]

It's not yet 100% defined, but spec is leaning towards only mapping regular commonjs exports to default

airbnb/babel-plugin-dynamic-import-webpack#12

At any rate, it would always be more compatible to be strict. If the spec is relaxed later, the rule might be relaxed in a semver-minor version, but making it stricter would be semver-major.

[sokra]

As far I know it's undefined so I decided for a behavior similar to import * as x from ....

// fs.js
exports.readFile = function() {}

import("./fs").then(fs => a.readFile())

import * as fs from "./fs";
fs.readFile();

The way babel does it is just complex and weird:

import("./fs").then(fs => fs.default.readFile())

import * as fs from "./fs";
fs.default.readFile();

And it requires wrappers that increase bundle size.

---

As the spec doesn't define a behavior here I'm free to do whatever I want. It's rar anyway.

[Jessidhia]

It is true that import() is the same thing as a namespace import, though. The import * as x from behavior itself is what is being questioned -- it might not be allowed to pluck keys from an object export if it's a commonjs export. It doesn't help that commonjs exports are not necessarily objects...

[bmeck]

@sokra as @Kovensky said, when Node ships ESM the ModuleNamespace Objects that are created for CommonJS may not have named properties for things. The discussions of the exact nature of CommonJS and creating a standard interop (standardized by Node, which is the default maintainer of CommonJS these days) is under the https://github.com/nodejs/node-eps repository and is under various agenda items in TC39. The standard interop will not land in ECMA262 just like how CommonJS is never going to land in ECMA262. However, there are JIT reasons why named imports from CommonJS may never land, and the future safe option is to only provide a default export that maps to module.exports for now. The existing ECMA262 ModuleNamespace Object type cannot fully map to CommonJS module.exports for now and a wrapper must be used to be spec compliant.

[sokra]

Please reference files here with the {{templates/b.js}} notation. Don't repeat code.