Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement Proposal: dynamic imports #344

Closed
kaicataldo opened this issue Jun 20, 2017 · 13 comments
Closed

Enhancement Proposal: dynamic imports #344

kaicataldo opened this issue Jun 20, 2017 · 13 comments

Comments

@kaicataldo
Copy link
Member

Now that dynamic imports are now stage 3 and are used by Webpack v2 for code splitting, I'd like to propose we add support for this in Espree/ESLint behind an option like experimentalDynamicImport: true.

An Acorn plugin already exists, and it looks like it's well used: https://www.npmjs.com/package/acorn-dynamic-import

@kaicataldo
Copy link
Member Author

For reference, at my place of work, we're using babel-eslint just for dynamic imports right now.

@mysticatea
Copy link
Member

mysticatea commented Jun 20, 2017

My state is negative about supporting stage 3. There are some reasons.

  • there is a precedent that a stage 3 proposal dropped; simd
  • after we implemented rest spread properties, AST of the syntax changed without compatibility. Now, there are 3 kinds of AST; espree's, babel-eslint's, and ESTree's. It's confusing.
  • stage 3 is unstable. Chrome beta enables rest properties by default, but the syntax has been changed in the last tc39 meeting. Chrome's syntax is now non-standard.
  • babel-eslint is supporting experimental syntax.

@kaicataldo
Copy link
Member Author

@mysticatea In general, I agree. This feels like a special case to me because of Webpack. Personally, I think it doesn't feel great to have to use another parser to get code splitting in such a ubiquitous tool.

@mysticatea
Copy link
Member

Doesn't webpack support require?

@kaicataldo
Copy link
Member Author

Yeah, it's also possible to use require.ensure() instead of import(). I suppose that's a fair argument.

@soda0289
Copy link
Member

Would it be possible to make espree an acorn plugin? Then you could just use acorn with eslint and use any plugin you wanted.

@kaicataldo
Copy link
Member Author

@soda0289 Relevant discussion: #334

@nzakas
Copy link
Member

nzakas commented Jul 7, 2017

Also 👎 Our position has always been that using experimental features requires using Babel. Babel does a really good job at supporting them, and as long as Babel-ESLint exists, I don't think we should change our policy on this.

@kaicataldo
Copy link
Member Author

With 2 👎s from TSC members, in going to close this.

@tschaub
Copy link

tschaub commented Oct 14, 2020

Should a new issue be opened now that dynamic imports are at Stage 4 (tc39/proposal-dynamic-import#78)?

@mdjermanovic
Copy link
Member

@tschaub espree supports dynamic imports since v6.1.0, if the ecmaVersion is set to 2020 or higher.

Ref #415

@tschaub
Copy link

tschaub commented Oct 15, 2020

Thanks, @mdjermanovic.

Different subject, but I’m curious if there is discussion somewhere about why the default for ecmaVersion is kept so low.

@kaicataldo
Copy link
Member Author

@tschaub It's been discussed many times in the eslint/eslint repo (and we've had proponents both for keeping ecmaVersion as it is currently and setting to latest), but the summary is that we've erred on the safer side of things by making new syntax opt-in rather than opt-out. This means that someone running their code in an environment that doesn't support the latest syntax would never accidentally push code that couldn't execute to production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants