Reputation: 110
I've setup eslint with google style and found the following code being flagged with new-cap
:
import {Deserialize} from 'cerialize';
//...
const someVar = Deserialize(someJson, someType);
Well the notion makes sense, eslint wants it to be camelCased. But that's 3rd party code and I don't really have a good fix against it.
// eslint-disable-next-line
every call on that function, because it feels pretty dumb.import {Deserialize as deserializeFunc} from 'cerialize';
The fundamental question is, why is the rule checked against the caller? My code doesn't seem to be blamed, it's a callee from another library who's not following that naming rule. Of course it's not even their responsibility because the author of that library might be using other coding style.
Is eslint designed to force me to ban libraries that doesn't have the same style? Or is there any fix or options that I'm missing?
Upvotes: 0
Views: 302
Reputation: 110
This rule is basically copied from JSHint for compatibility with existing style guides. This came back from before ESM, so there was no way to tell if something was library code or not.
(https://github.com/eslint/eslint/discussions/15722#discussioncomment-2434062)
As it turns out, this was not an intended design but a limitation from a pre-ESM linter rule.
Upvotes: 0
Reputation: 371203
It's designed to get you to fix your code if you happen to be in control of the export. The linter is not intelligent enough to determine whether you do or not, so it errs on the side of prompting you to fix it if you can.
In this case, you don't control that library, so you should add an exception for Deserialize
(and any other such imports with oddly capitalized names).
"new-cap": ["error", { "capIsNewExceptions": ["Deserialize"] }]
Upvotes: 1