Estoy confundido acerca de qué paquete se resolverá, cuándo hay varios y cómo obtener el correcto.
Debido a que intenté bifurcar las reglas básicas de eslint, consideré 1 usando una bifurcación de eslint
. En este caso, se haría usando el protocolo de parche, para evitar tener que mantener una bifurcación. Ahora, como eslint
y él mismo aplicarán linting al paquete, ahora hay dos dependencias de eslint:
"devDependencies": { "eslint": "^8.3.0", "plugin-for-core-rule-forks": "portal:.", ... } "dependencies": { "eslint": "patch:eslint@npm:8.3.0#eslint-npm-8.3.0-somenumber", ... }
Esto conduce a problemas. Parece funcionar cuando se usa el paquete desde otro lugar, aunque ya tuve que eliminar la entrada peerDependencies
de eslint
, que el complemento suele tener. Sin embargo, dentro del propio paquete, las reglas ahora tienen su require('eslint/...')
resuelto en el eslint
sin parchear de devDependencies
, que falla. Empecé a leer sobre alias de paquetes, pero el problema es más profundo:
eslint
a su vez tienen eslint
en sus peerDependencies
y es posible que no acepten la versión con aliaseslint
pueden, a su vez, require
partes de eslint
, y sería difícil buscarlos todos para cambiar al alias. ¿Puedo de alguna manera asegurarme de que una vez dentro de una versión de eslint
, no salte repentinamente a la otra? ¿Cómo puedo separar correctamente los dos eslint
s diferentes, sin romper cada require
, peerDependencies
u otra interacción con eslint
, dentro o relacionada con la bifurcación?
1: Como esto resulta demasiado complejo, y más como un clusterf ***, probablemente terminaré usando un método para ignorar la directiva de exports
, que no requiere una bifurcación. Esto es mucho más simple, pero significa que si eslint
no cambia su API privada, pueden ocurrir fallas.