¿Cómo usar referencias de proyectos en TypeScript 3.0?

Nuestros investigadores estrellas agotaron sus depósitos de café, en su búsqueda todo el tiempo por la solución, hasta que Ernesto halló la solución en GitHub y hoy la compartimos contigo.

Solución:

TL; DR:

La función permite definir partes del proyecto como módulos TypeScript separados. Entre otras cosas, esto permite configurar esos módulos de manera diferente, construirlos por separado, etc.

---

Antes

Inicialmente, la estructura del proyecto, cuando se simplifica, es similar a esto:

/
    src/
        entity.ts # exports an entity
    test/
        entity.spec.ts # imports an entity
    tsconfig.json

_{Una entidad se define en src/entity.ts módulo, y luego se utiliza en test/entity.spec.ts expediente.}

Note que solo hay uno tsconfig.json archivo aquí, ubicado en la carpeta raíz. Esto básicamente dice que esta carpeta contiene un gran proyecto sólido de TypeScript. Este proyecto incluye un par de archivos, organizados en carpetas; algunos de esos archivos se utilizan para probar otros.

Sin embargo, esta estructura impone un problema: el proceso de compilación del proyecto (es decir, tsc) también compila los archivos de prueba, creando así dist/test/entity.spec.js archivos en la salida. Esto no debería suceder, por lo tanto, el tsconfig.json El archivo se modifica ligeramente para incluir solo aquellos archivos / carpetas que están destinados a uso externo:

    "compilerOptions": 
        // compiler options
    ,
    "include": [
        "./src"
    ]

Esto resuelve el problema, pero en mi caso también llevó a todos los archivos en /test que el compilador de TypeScript ignora ocasionalmente durante el proceso de desarrollo. Además, este enfoque exclusivo podría no ser adecuado para todos.

---

Después

Después de utilizar la función, la estructura del proyecto ha cambiado a esto:

/
    src/
        entity.ts # exports an entity
        tsconfig.json
    test/
        entity.spec.ts # imports an entity
        tsconfig.json
    tsconfig-base.json

Repasemos los cambios:

1. Renombrar /tsconfig.json para /tsconfig-base.json es algo bastante importante en sí mismo: la carpeta raíz ya no es un proyecto de TypeScript, ya que tsc requiere tsconfig.json archivo para estar presente.
2. Por otro lado, agregando src/tsconfig.json y test/tsconfig.json los archivos se vuelven ambos src y test en dos proyectos TypeScript separados, independientes entre sí.

Los contenidos de /src/tsconfig.json Los archivos son similares, ya que no se esperaban cambios en la configuración, es decir, el “rigor”, la carpeta de salida, así como otros parámetros similares, deben conservarse. Para hacerlos similares sin copiar y pegar nada, todas las configuraciones se colocan en un archivo arbitrario, accesible desde ambos lugares; en este caso, el tsconfig-base.json en la carpeta raíz se seleccionó para eso:

// the contents of /tsconfig-base.json

    "compilerOptions": 
        // compiler options, common to both projects
    

Este archivo está siendo “heredado” por /test/tsconfig.json archivos, con la adición de cualquier otra opción si es necesario:

// the contents of /test/tsconfig.json

    "extends": "../tsconfig-base.json",
    "compilerOptions": 
        // additional compiler options, specific to a project
    

Observe cómo este patrón es similar a definir un abstract class con implementación incompleta, y luego extendiéndola en dos clases “concretas” separadas.

Ahora, /src y /test Las carpetas contienen básicamente dos proyectos TypeScript separados con una configuración similar. Lo último que debe hacer es especificar la relación entre los dos. Ya que test depende de src, los test tengo que “saber” de alguna manera sobre src. Esto se hace en dos pasos bastante obvios:

• permitir src para ser “referenciado” desde el exterior declarándolo como “compuesto”:

  // in /src/tsconfig.json
  
      "extends": "../tsconfig-base.json",
      "compilerOptions": 
          // compiler options
          "composite": true
      
  
  

• referencia src de test:

  // in /test/tsconfig.json
  
      "extends": "../tsconfig-base.json",
      "references": [
           "path": "../src" 
      ]
  
  

los "include" array en /tsconfig-base.json no es necesario ahora, ya que la exclusión del código se realiza “dibujando nuevos bordes”.

ACTUALIZACIÓN: la siguiente sección parece estar desactualizada desde TypeScript 3.7

Ahora el test el proyecto requiere *.d.ts archivos para src proyecto para estar presente. Esto significa que antes de ejecutar las pruebas, el src ya debería estar construido, por separado. Esto se hace usando el nuevo modo de tsc, desencadenado por --build opción:

tsc --build src

Este comando construye src proyecto y coloca la salida en la carpeta de salida especificada (en este caso, /dist), sin que se rompa test, ni perder errores de compilación.

es para las bibliotecas de mecanografiado que desarrolla, que son utilizadas por otras aplicaciones de mecanografiado. Entonces, por ejemplo, si crea alguna biblioteca útil como lodash pero lo están desarrollando activamente junto con su aplicación dependiente, el references en “ tsconfig.json“` le permite hacer referencia al código fuente y hacer que su aplicación dependiente se reconstruya automáticamente cuando cambia la fuente de la utilidad (IE: tsc detecta cambios en el código fuente en la lib de util ts)

En mi caso específicamente, utilizo el references en conjunto con npm link y git submodules y está funcionando mucho mejor que en el ts 2.x dias.

---

---

Utiliza Nuestro Buscador