Ben Mosher

`eslint-plugin-node` has [`no-unpublished-requires`](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-unpublished-require.md). I'd be up for something similiar in `eslint-plugin-import` but what's there in the `node` plugin might work as-is? (though I don't know if that plugin handles ES6...

Ah, yeah, not so much a bug as a missing feature. 😅 It's tough to disambiguate "project" dependencies from `node_modules` dependencies ATM, so aliases may not play nicely with `no-extraneous-dependencies`.

@simonbuchan I suspect that's true. `externals` has a similar property to `aliases` in that it results in more path-resolution magic than `no-extraneous-dependencies` is prepared to handle. Though I wouldn't be...

Upon further reflection, this is another case of #479, should be solvable the same way.

https://github.com/benmosher/eslint-plugin-import/issues/496#issuecomment-282559042 @mudrz is your file on the filesystem `foo` or `foo.js`? if it's the latter, I'm surprised it doesn't work. if it's the former, I would believe that the resolver...

FWIW, I like to outsource lifecycle method work to (other) named methods in order to ensure they remain segmented by concern. This rule only looks for `this.setState` in the body...

I can imagine having two separate rules: `compat/apis` vs. `compat/syntax`. Would be neat. I also am mostly looking for linting of APIs since `babel-preset-env` handles pretty much every modern syntax...

Sounds useful to me. Future maintenance is always a factor but I don't think this would be a very substantial rule. I think the implementation might be similar to [`no-named-as-default`](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-named-as-default.md)....

btw @ljharb I marked `accepted` but feel free to remove it if you still have concerns.

What TS parser are you using? I don't think it's the resolver, I think it's the TS parser rewriting the path before the lint rule runs.