Bienvenido a proyecto on line, en este sitio hallarás la resolución que buscabas.
Solución:
los paths mapeo que establezcas en tu tsconfig.json es puramente un tiempo de compilación cartografía. No tiene ningún efecto en el código generado por el compilador de TypeScript. Es por eso que tiene un error en tiempo de ejecución. Eso es algo que se ha informado al proyecto TypeScript, lo que sugiere que tsc debe traducir automáticamente las rutas del módulo en el código emitido para ajustarse al mapeo establecido por paths. Los desarrolladores de TS respondieron tsc está funcionando según lo previsto y que la solución es configurar un cargador de módulos que realice en tiempo de ejecución un mapeo similar al establecido por paths.
Aqui lo que pienso usted debería hacer, en función de cómo describió su caso.
Estoy asumiendo que midi-app es una aplicación de prueba que no debe distribuirse. Debería poder seguir usando el paths mapeo que tienes sin ningún problema. (No ha mencionado ningún problema al ejecutar esta aplicación. Por lo tanto, parece que sus herramientas ya se encargan del problema del tiempo de ejecución).
Para midi-lib, Dejaría de depender de las asignaciones establecidas por paths y solo usa rutas relativas. Esta es una biblioteca, destinada a ser consumida por otros. Debido a esto, cualquier configuración que corrija la asignación del nombre del módulo en el tiempo de ejecución (o en el momento de la agrupación) tendría que ser manejada por los consumidores de su biblioteca. Los consumidores que utilicen Webpack deberán agregar una configuración a su configuración de Webpack para proporcionar el mapeo correcto. Los consumidores que usan Rollup tendrían que hacer lo mismo con Rollup. Los consumidores que usan SystemJS tendrían que hacer lo mismo con SystemJS, etc.
Además, la configuración requerida podría complicarse según el contexto en el que se utilice su biblioteca. Siempre que su biblioteca sea la sólo uno necesitando mapear @lib a alguna ruta, el mapeo que debe agregarse a Webpack (o SystemJS, etc.) puede ser global. El paquete de módulos o el cargador de módulos siempre reemplazarán @lib con tu ruta, lo cual está bien porque tu paquete es el solamente uno que necesita @lib reemplazado. Sin embargo, suponga que otro autor de biblioteca hace exactamente lo que usted hizo, y un consumidor de su biblioteca también usa esa otra biblioteca. Ahora tienes una situación en la que @lib debe asignarse a una ruta en algunos casos y debe asignarse a otra ruta en otros casos. Esta pueden configurarse, pero requiere una configuración más compleja.
Me he centrado en el problema de resolver los módulos durante la agrupación o al cargarlos en tiempo de ejecución, pero hay otro problema. Los consumidores también necesitarían configurar sus tsc compilación con una configuración especial porque el .d.ts archivos
Si solo usa rutas relativas en su código, los consumidores de su biblioteca no tendrán que preocuparse por agregar configuraciones especiales para adaptarse a las necesidades especiales de su biblioteca.
Hay un caso especial que puede encajar con su caso. Si su biblioteca se publicará como midi-lib entonces puedes cambiar tu paths mapa para que en lugar de @lib/* tienes un mapa para midi-lib/*:
"midi-lib/*": ["projects/midi-lib/src/*"],
(Tenga en cuenta que el @ símbolo no tiene un significado especial en lo que respecta a TypeScript. También tenga en cuenta si su paquete está destinado a instalarse con un alcance, como @midi-project/midi-lib entonces necesitas el alcance en el tsconfig.json mapeo también: "@midi-project/midi-lib/*": ...)
Básicamente, el objetivo aquí es establecer un mapeo que le permita importar módulos en su proyecto exactamente de la misma manera que un consumidor de su proyecto importaría módulos individuales de él. Si un consumidor de su módulo importaría el ParseService con import ParseService from "midi-lib/lib/service/parse.service", luego en tu propio código usarías el mismo import cuando desee utilizar ese módulo. (Tenga en cuenta que no importa si les dice a los consumidores que importen este módulo directamente. Si los consumidores debían importar el módulo directamente, luego ¿Qué camino usarían?) Entonces, la misma ruta funciona en tiempo de compilación y en tiempo de ejecución (o tiempo de agrupación). En tiempo de compilación, tsc convierte el camino. En el tiempo de ejecución o el tiempo de agrupación, el algoritmo de resolución del módulo de Node (o una herramienta que puede seguir el mismo algoritmo, como Webpack o Rollup) convierte la ruta.
La cantidad de mecanografía que ahorraría con esto depende en gran medida de los nombres que haya elegido y de cómo haya estructurado su biblioteca.
En teoría, podrías tener un paso después de correr. ng build que repasaría los archivos producidos por ng build y reemplazar @lib en los nombres de los módulos con la ruta real a la que se supone que debe apuntar. Los problemas con esto:
-
No se trata solo de ejecutar una sola herramienta o cambiar una bandera en una opción de configuración. Tal vez una herramienta como
rolluppuede transformar los archivos JS, pero ahora necesita aprender cómo funciona y escribir una configuración para él. -
AFAIK, no hay una herramienta disponible que transforme la
.d.tsarchivos a medida que los necesite. Lo más probable es que tengas que escribir tu propia herramienta. -
También necesitaría parchear los metadatos de compilación AOT generados por el compilador Angular AOT porque también contiene referencias de módulos, y estas referencias son utilizadas por los consumidores de su biblioteca. AFAIK, no existe tal herramienta. Así que aquí también tendrías que enrollar el tuyo.
-
Su proceso de compilación podría interrumpirse si una nueva versión de Angular cambia el formato de los metadatos de compilación de AOT o agrega un tipo diferente de archivo de metadatos que necesita parches. Lo sé por experiencia: tengo un par de paquetes que son aplicaciones angulares altamente experimentales. Por razones históricas, omiten por completo el uso de Angular CLI para la construcción. Cada actualización de Angular desde la versión 4 en adelante rompió algo en el proceso de construcción de estas aplicaciones. A menudo tenía que ver con cómo se manejaban los metadatos de compilación de AOT.
Ten en cuenta mostrar este escrito si te ayudó.