Enhancement Proposal: dynamic imports
See original GitHub issueNow 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
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:13 (11 by maintainers)
Top Results From Across the Web
1342012 - Implement the dynamic import() proposal
A proposal for adding a "function-like" import() module loading syntactic form to JavaScript. It is currently in stage 3 of the TC39 process....
Read more >@babel/plugin-proposal-dynamic-import - Package Manager
Fast, reliable, and secure dependency management.
Read more >ECMAScript - Introducing Dynamic Imports in ES2020 (ES11)
... explains the motivation and abilities of the " Dynamic Import " proposal, ... My mission is to enhance the web development community...
Read more >@babel/plugin-proposal-dynamic-import - npm
Transform import() expressions. Latest version: 7.18.6, last published: 4 months ago. Start using @babel/plugin-proposal-dynamic-import in ...
Read more >Next.js With Dynamic Import Example (forked) - StackBlitz
This examples shows how to dynamically import. modules via [`import()`](https://github.com/. tc39/proposal-dynamic-import) API. ## Preview.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@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.
@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.