0
319
VisualizaçõesWhy is an eslint rule applied against the caller? (new-cap)
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.
- I don't want to disable new-cap rule globally because I'm willing to enforce that rule in my code.
- I don't want to
// eslint-disable-next-lineevery call on that function, because it feels pretty dumb. - Nor to alias every import for the same reason:
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?
2 Respostas
Responde à pergunta0
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"] }]
0
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.