-
-
Notifications
You must be signed in to change notification settings - Fork 209
babel-eslint not compatible with no-unused-vars: [2, {vars: local}]
#136
Comments
I don't think this would be a |
@nzakas - this isn't really a |
If it works OK with the default parser, and Esprima, then it must be a babel-eslint issue. |
Ok it's because |
no-unused-vars: [2, {vars: local}]
Ok after doing some more looking it seems like it's because we are doing ecmaFeatures:
modules: true
rules:
no-unused-vars: [2, {vars: local}] and it also will error with the regular parser. |
I see.. the monkey patching basically affects all subsequent linting. For now I can just change my script to switch the order to have the directory that uses babel-eslint be the last. |
FWIW, Babel is probably going to get the ability to load ESLint rules rather than hacking around ESLint internal APIs and monkeypatching them. |
What would be necessary in the ESLint side to prevent you from needing to monkey patch or otherwise load rules directly? |
There's no way for people using Babel to ever use ESLint as a first class citizen. It'd mean putting all of this into ESLint core, escope etc. |
Yikes! Okay, at some point I'll dig in and see what's going on there. |
Yeah that part is comment attachment, supporting |
I guess we'll just close this for now with the workaround being what @kentor said:
|
Ok I have this setup:
A/.eslintrc
:A/a.js
:B/.eslintrc
:B/b.js
:package.json
:Running eslint on dir A and B gives the expected result:
however, running it on dir B and A gives an additional unexpected error on
a.js
:This only happens when using babel-eslint as the parser for directory B. I've tried the default parser, esprima, and esprima-fb and it does not throw the error for
a.js
. The result shouldn't change given the order of directories given to eslint right?The text was updated successfully, but these errors were encountered: