Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add option to tolerate non-top-level `import`s in ES6 mode
See original GitHub issueRe-filed from https://github.com/eslint/eslint/issues/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.
Issue Analytics
- State:
- Created 8 years ago
- Comments:10 (5 by maintainers)
Top Results From Across the Web
Add option to tolerate non-top-level import s in ES6 mode #2259
The ES6 spec only allows imports at the top-level of a module (i.e. not nested inside another block, such as a function body,...
Read more >Pass options to ES6 module imports - Stack Overflow
Solution? This is what I'm thinking about: use query parameters. In the service we'd add the following: let context = new ...
Read more >16. Modules - Exploring JS
An ES6 module can pick a default export, the main exported value. Default exports are especially easy to import. The following ECMAScript 6...
Read more >import - JavaScript - MDN Web Docs - Mozilla
Standard Import. In this example, we create a re-usable module that exports a function to get all primes within a given range.
Read more >Avoid these issues when using new ECMAScript modules in ...
js is running in ECMAScript es6 module mode. There is an alternative method for getting the current working directory available to you in...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top 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
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
import()is not a part of ES2015. It’s a stage 3 proposal: https://github.com/tc39/proposal-dynamic-import