Non-top-level imports are basically part of the ES6 specs, take out warning

[mercmobily]

What rule do you want to change?

"Import and export may only appear at the top level" (sorry, can't find the ID)

This is because now, in 2019, import()s are pervasively used, and basically part of the specs -- the last comment in particular from yesterday reads "Investigated. Discussed in the SES meeting today. We are happy to see this proceed to stage 4."

Does this change cause the rule to produce more or fewer warnings?

Fewer.

How will the change be implemented? (New option, new default behavior, etc.)?

Disable a rule when linting ES6

Please provide some example code that this change will affect:

    case 'view1':
      import('../components/my-view1.js').then((module) => {
        // Put code in here that you want to run every time when
        // navigating to view1 after my-view1.js is loaded.
      });
      break;

What does the rule currently do for this code?

Gives a warning

What will the rule do after it's changed?

Stop giving the warning

Are you willing to submit a pull request to implement this change?

Sorry, I don't know eslint's code base at all

[not-an-aardvark]

Hi, thanks for creating an issue.

Dynamic import is still a stage 3 proposal, so we don't support it yet. Based on the link you shared, it seems like it will probably reach stage 4 soon, which is great news. As with all other features, we'll start supporting it once it reaches stage 4.

[mercmobily]

From the horse's mouth:

"I expect it to happen at the upcoming tc39 meeting June 4,5,6 2019"

Is a PR ready for it? (maybe one of the ones that was rejected because it wasn't stage 4 yet?)
I am hoping this change will make it to the codebase as soon as imports are promoted to stage 4. I am happy to do whatever to facilitate that.

[platinumazure]

@mercmobily If this is really likely to make stage 4, contributions would be great! Here's a (likely incomplete) list of what would be needed:

• Is there an ESTree spec for this? (I hope the tc39 champion would write a PR there, but worth checking.)
• Does Acorn support this? If not, need to ensure Acorn can parse. (Best would be if it happened in mainline Acorn, but if they are unlikely to get it in soon, espree could maybe consume an Acorn plugin- see next.)
• Espree would need to consume new Acorn (upgrade dependency, or maybe consume plugin if needed). Espree would also need to convert Acorn output to match ESTree spec, add unit tests, etc.
• ESLint would need to consume new espree version once it is released. Additionally, rules might need to be updated (e.g., make sure no-undef doesn't report import as an identifier with no declaration.

My suggestion is to start upstream and see what's in place already, then work down to ESLint. Some of the upstream repositories might be willing to accept PRs early.

Hope this helps!

[mercmobily]

Hi,

OK, let's do this!
Hopefully, this will help things speed up a little.

"Is there an ESTree spec for this? (I hope the tc39 champion would write a PR there, but worth checking.)"

YES. It looks merged too. estree/estree#137

"Does Acorn support this? If not, need to ensure Acorn can parse. (Best would be if it happened in mainline Acorn, but if they are unlikely to get it in soon, espree could maybe consume an Acorn plugin- see next.)"

YES. It does so via a Acorn plugin for dynamic imports. I opened a ticket to see if they will move the dynamic imports plugin to the main codebase

For the last 2 points... does it all relate to Eslint's codebase?

Merc.

[mysticatea]

I would make the umbrella issue for ES2020 after the next TC39 meeting if the syntaxes really arrived at Stage 4, like I have done so in the past.

• Stage 4 syntaxes in core rules #7101 ... ES2017 (async/await)
• 🎉 Object Rest/Spread Properties arrived at stage 4 #9885 ... ES2018 (Rest/spread properties)
• 🎉 Asynchronous Iteration arrived at Stage 4. #9891 ... ES2018 (Async iteration)
• RegExp enhancements in ES2018 #9893 ... ES2018 (RegExp literal enhancements)
• Support new syntax features in ES2019 #10392 ... ES2019 (optional catch binding and JSON superset)

---

YES. It looks merged too. estree/estree#137

It's in the experimental directory that ESLint core doesn't support. It's needed to move it to the es2020.md.

For the last 2 points... does it all relate to Eslint's codebase?

Yes.

• Espree is the default parser of ESLint. For reference, Update: upgrade acorn to support two ES2019 syntax espree#380 was the PR to support ES2019.
• And we have to investigate ESLint core rules to support new syntaxes. For reference, Stage 4 syntaxes in core rules #7101 was an umbrella issue for ES2017.

[mysticatea]

Hi. Please track #11803.