You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
no-common won't detect AMD modules... should the arms race of specific non-ES6 module types continue (more come to mind) or should it be retooled to report all import statements with specifiers* that point to a resolved module without ES6 syntax?
A thought: this would probably be cheaper to implement, as export syntax may only be present in the root scope. Would not need to traverse any deeper than the body, which means estraverse goes away and an empty ExportsMap is the harbinger of this report.
Also removes the need for "es6-only" as a setting for any rules.
I think I've sold myself on es6-only as a first-class rule, and dropping no-common + rule-specific measures.
note: this implicitly precludes imports such as import 'module'. Which makes sense.
The text was updated successfully, but these errors were encountered:
no-common
=>es6-only
? or addno-amd
?no-common
won't detect AMD modules... should the arms race of specific non-ES6 module types continue (more come to mind) or should it be retooled to report all import statements with specifiers* that point to a resolved module without ES6 syntax?A thought: this would probably be cheaper to implement, as
export
syntax may only be present in the root scope. Would not need to traverse any deeper than the body, which meansestraverse
goes away and an emptyExportsMap
is the harbinger of this report.Also removes the need for
"es6-only"
as a setting for any rules.I think I've sold myself on
es6-only
as a first-class rule, and droppingno-common
+ rule-specific measures.import 'module'
. Which makes sense.The text was updated successfully, but these errors were encountered: