Configuré eslint con el estilo de Google y encontré el siguiente código marcado con new-cap :
import {Deserialize} from 'cerialize'; //... const someVar = Deserialize(someJson, someType);Bueno, la noción tiene sentido, eslint quiere que sea camelCased. Pero ese es un código de terceros y realmente no tengo una buena solución contra él.
// eslint-disable-next-line cada llamada a esa función, porque se siente bastante tonto.import {Deserialize as deserializeFunc} from 'cerialize';La pregunta fundamental es, ¿por qué se compara la regla con la persona que llama? Mi código no parece tener la culpa, es un destinatario de otra biblioteca que no sigue esa regla de nomenclatura. Por supuesto, ni siquiera es su responsabilidad porque el autor de esa biblioteca podría estar usando otro estilo de codificación.
¿Eslint está diseñado para obligarme a prohibir las bibliotecas que no tienen el mismo estilo? ¿O hay alguna solución u opciones que me faltan?
Está diseñado para que arregles tu código si tienes el control de la exportación. El linter no es lo suficientemente inteligente como para determinar si lo hace o no, por lo que se equivoca al pedirle que lo arregle si puede.
En este caso, no controla esa biblioteca, por lo que debe agregar una excepción para Deserialize (y cualquier otra importación similar con nombres en mayúsculas extrañas).
"new-cap": ["error", { "capIsNewExceptions": ["Deserialize"] }]Esta regla básicamente se copia de JSHint para compatibilidad con las guías de estilo existentes. Esto vino de antes de ESM, por lo que no había forma de saber si algo era código de biblioteca o no.
( https://github.com/eslint/eslint/discusiones/15722#discusióncomentario-2434062 )
Resulta que este no era un diseño previsto, sino una limitación de una regla de linter anterior al ESM.