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.

Unambiguous ES module rule

See original GitHub issue

Currently, Script and Module goals have a grammatical ambiguity where some code can run in both goals, having the exact same source text, but produce different results. Unlike "use strict", the signal to have a specific behavior is not in the code, thus the code has a multitude of possible effects which are not controlled by the programmer.

Because of this I think a new rule for unambiguous ES modules would be nice. It could even be enabled by default when "parserOptions": { "sourceType": "module" }. The rule would enforce that an ES module should have at least one import or export declaration.

\cc @mikesherov @ilyavolodin

Issue Analytics

State:
Created 7 years ago
Reactions:1
Comments:19 (11 by maintainers)

Top GitHub Comments

3reactions

jdaltoncommented, Aug 2, 2016

Thanks @nzakas!

For those interested the unambiguous rule has been added to v2 of eslint-plugin-import. As previously mentioned it has benefits regardless of Node/TC39 roadmaps!

0reactions

nzakascommented, Aug 2, 2016

Okay, this reinforces my belief that it’s too soon to consider this for the core. It’s now past our 21-day period to accept issues, so I’m closing. If the unambiguous module syntax reaches standardization and/or implementation, please open another issue and we can consider it again. In the meantime, a custom rule would be your best approach.