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é ¹ 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:

• algunos paquetes de los que depende eslint a su vez tienen eslint en sus peerDependencies y es posible que no acepten la versión con alias
• algunos paquetes de los que depende eslint 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.