Add option to tolerate non-top-level `import`s in ES6 mode

[cvrebert]

Re-filed from eslint/eslint#2259

One possible implementation strategy: Make the tolerant option more fine-grained. Allow its value to be an object specifying individual things to tolerate, rather than just a single all-or-nothing boolean.

[nzakas]

I'll take a look. I don't want to change the behavior of tolerant for Esprima compatibility, but depending on how easy of a change this is, I'll see what other options are available.

[ritz078]

Any updates regarding this ? Its really important for me as i want to create a custom build.

[nzakas]

It's unlikely we will add this as no formal ES6 engine will support this syntax.

[cvrebert]

Um, do Esprima harmony, Acorn, Babel, and JSCS all somehow not count?:

• jquery/esprima@b1dd29e
• export and import are not statements acornjs/acorn#174
• https://babeljs.io/docs/usage/loose/#es6-template-literals (see the es6.modules option)
• Allow non-top-level ES6 import declarations jscs-dev/node-jscs#952

Or by "formal ES6 engine" do you mean ES VMs?

[ritz078]

For now i had to use require instead of import with webpack.

[nzakas]

@cvrebert that's correct, they don't count. Using non-top level imports will not work with native ES6 implementations. Babel allows it because it transpiles to CommonJS require, but it is technically not allowed in ES6.

@ritz078 that is the correct thing to do for interop

[cvrebert]

Using non-top level imports will not work with native ES6 implementations.

Of course, but why does ES6-proper matter so much? We'll probably be transpiling to ES5 for the next half-decade at least. And the extension in question is very straightforward.

[nzakas]

Whether or not an incorrect syntax is easy to implement is not relevant. I don't want to encourage people to rely on syntax that they'll one day have to remove. Feel free to use the other parsers you mentioned if you'd like to use incorrect syntax.

[ntucker]

@nzakas Strange, this spec https://whatwg.github.io/loader/ says import() can appear anywhere. And is used https://webpack.js.org/guides/code-splitting-import/ in webpack 2.

[mysticatea]

@ntucker import() is not a part of ES2015. It's a stage 3 proposal: https://github.com/tc39/proposal-dynamic-import