Hola @lazutkin. Actualmente eso no es compatible, aunque solo quiero vincular este problema al # 2869 porque está algo relacionado.

El compilador elige el tsconfig.json más cercano a la carpeta que está creando si está ejecutando tsc sin argumentos en una carpeta. por lo que si tiene un directorio interno con tsconfig.json, se seleccionará antes que el del directorio externo.

No creo que admitamos la configuración de integración / anulación de múltiples tsconfig.json.

Varios archivos tsconfig son indispensables para las grandes aplicaciones empresariales.
Sugerencia: Cada vez que tsc encuentra un nuevo archivo tsconfig en un subdirectorio, tsc se detiene aquí y crea un nuevo proceso tsc con su propio archivo tsconfig.

@Eisenspalter, esto suena como un trabajo de controlador de compilación, algo como gruñido, gulp o msbuild.

@mhegazy Estoy de acuerdo con @Eisenspalter porque ambos no hablamos sobre el proceso de construcción, sino sobre el proceso de desarrollo, incluida la escritura de fuentes, las pruebas y otras actividades que debemos completar antes de la construcción. En todos estos pasos intermedios necesitamos tener soporte de typescript incluyendo intellisense, typechecking, etc. Además, como dije antes, para diferentes partes del proyecto nos gustaría aplicar diferentes técnicas de organización de fuentes (módulos externos-internos, single archivo de salida, etc.) y aquí necesitamos que algunas opciones sean anuladas por tsconfig por separado.

@mhegazy ¿

puede tener varios tsconfig hoy, cada uno apuntando a un conjunto de archivos superpuestos. así que uno en srctsconfig.json, uno en teststsconfig.json, etc. el compilador / herramientas localizará el archivo subiendo por el árbol de directorios para encontrar el más cercano. para que pueda tener un tercer archivo en la raíz para capturar todo.

Todo esto funciona hoy, en el compilador y en los diferentes IDE. el problema original era permitir que un archivo heredara de otro. No creo que haya suficiente valor allí, justifica la complejidad.

Para el segundo número:

Cada vez que tsc encuentra un nuevo archivo tsconfig en un subdirectorio, tsc se detiene aquí y crea un nuevo proceso tsc con su propio archivo tsconfig.

Como mencioné anteriormente, un tsconfig.json representa una única invocación a tsc.js / tsc.exe si desea hacer múltiples invocaciones, debe usar un controlador de compilación.

@lazutkin y @Eisenspalter ¿esto responde a las preguntas?

@mhegazy
No se pudieron hacer funcionar varios tsconfig.json. Al menos con TypeScript 1.7.3, solo se lee un tsconfig.json y se espera que esté en el directorio raíz (o padre) del proyecto.

@Ziink, mi comentario anterior no se refería a múltiples tsconfigs en el mismo proyecto. se trataba de varios proyectos / directorios, cada uno con un tsconfig diferente. así es como se presenta el proyecto ts, consulte https://github.com/Microsoft/TypeScript/tree/master/src , cada carpeta en src, tiene un tsconfig.json diferente

Tengo un proyecto que está escrito en TypeScript y quiero apuntar a ambos:

1. navegador (digamos archivos en /browser ) con ES5 / AMD y
2. nodejs (archivos en server ) con CommonJS y generadores (y async / await en TS).

Hay algunos archivos compartidos, digamos en la carpeta ( /common ) y hay importaciones desde common a browser y server .
¿Cómo puedo lograr esa configuración conservando el soporte IDE, todos los errores, etc.? No estoy seguro de si la discusión respondió a mis dudas.

@bartq Con TS 1.8, crearía dos archivos tsconfig, uno para el navegador y otro para el servidor, y agregaría referencias /// en sus archivos en ambos subproyectos a los comunes. Pruébelo y háganos saber si esto aborda el escenario o si aún faltan piezas.

en realidad estoy usando esos dos archivos tsconfig.json , WebStorm los descubre y ejecuta la compilación automáticamente. Para ser precisos, el código de backend importa algunas clases del código de frontend (en su lugar, usa el concepto common ), pero todo funciona bien.

Finalmente consigo la solución.

mi estructura de aplicación:
- aplicación /- app / client / (mi código fuente del lado del cliente)- aplicación / servidor / (mi código fuente del lado del servidor)- app / build / (donde genero los js)- aplicación / módulos-nodo /- aplicación / paquete.json- aplicación / tsconfig.server.json- aplicación / tsconfig.client.json

Contenido de tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"excluir": ["node_modules", "cliente"]}

Contenido de tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"excluir": ["módulos_nodo", "servidor"]}

Luego, cuando quiero compilar el código fuente del servidor, uso este comando desde el directorio raíz de la aplicación:

tsc --p tsconfig.server.json

Y para compilar el código fuente del cliente, también desde el directorio raíz de la aplicación:

tsc --p tsconfig.client.json

Para ejecutar la compilación del cliente y del servidor, agregué un comando en package.json:

"scripts": {..., "tsc": "tsc --p tsconfig.server.json && tsc --p tsconfig.client.json", ...}

Luego, para compilar tanto el servidor como el cliente, simplemente ejecuto esto desde el directorio raíz de mi aplicación:

npm ejecutar tsc

Espero que este comentario pueda ayudarte :-)

No entiendo cuál es el problema aquí. ¿Por qué no podemos admitir configuraciones con diferentes nombres de archivo? Es un dolor tener que crear subcarpetas SÓLO para tener un archivo tsconfig diferente en formato.

Usted puede. --p argumento puede ser un nombre de archivo.

Sin embargo, los diferentes nombres de archivo no funcionarán con la extensión del compilador de mecanografía de Visual Studio (sin hablar de CLI) de fábrica. La única forma de hacerlo es poner cada tsconfig.json en un directorio ficticio y hacer que se vincule de nuevo a los scripts mecanografiados que desee con la opción files .

por ejemplo

--src / target / search / tsconfig.json
--src / target / core / tsconfig.json
--src / target / users / tsconfig.json

target / search / tsconfig.json se vería así:

{
  "compilerOptions": {
    "outFile": "../../../build/app/search.js"
  },
  "files": [
    "../../src/common",
    "../../src/search"
  ]
}

Y los demás serían similares.

Esto produciría 3 archivos javascript, cada uno con su propia configuración de archivos, agrupados en uno.

Por supuesto, podría usar una solución diferente de empaquetado / minimización / empaquetado que el propio compilador de TypeScript.

Es solo que el compilador de Typescript hace un muy buen trabajo con la optimización; ese es uno de los mayores atractivos del uso de Typescript.

Entonces, sería bueno si un solo tsconfig.json pudiera admitir múltiples configuraciones simplemente cambiándolo para que sea una matriz de tsconfigs:

[
  {
    "compilerOptions": {
      "outFile": "../../build/search.js"
    },
    "files": [
      "src/common",
      "src/search"
    ],
    "compileOnSave": true
  },
  {
    "compilerOptions": {
      "outFile": "../../build/core.js"
    }
    "files": [
      "src/common",
      "src/core"
    ],
    "compileOnSave": true
  }
]

Esto es lo que parece que se solicita en los comentarios posteriores de este problema, aunque estoy de acuerdo, el problema original era más sobre la herencia y las configuraciones anuladas.

@mhegazy @bartq No puedo hacer que funcione con el comando tsc .
Tengo una siguiente estructura de directorio

-- app/
-- app/server  -- here I want es6/commonjs
-- app/server/tsconfig.json
-- app/client    -- here I want es6/es6 
-- app/client/tsconfig.json
-- app/tsconfig.json

Sin embargo, cuando ejecuto tsc solo se usa la configuración de app/tsconfig.json , el resto se ignora. Estoy tratando de que funcione en VSCode: /

@tomitrescak Estoy usando WebStorm y es lo suficientemente inteligente como para encontrar el tsconfig.json más cercano y usarlo cuando edita un archivo. Probablemente no haya ninguna herramienta cmd que admita la visualización de múltiples tsconfig.json. Puede desplegarlo utilizando, por ejemplo, FB watchman.

Sí, me encantaría tener algo como esto en VS Code. Estoy ejecutando la compilación en la terminal. Funciona también. VS Code identifica correctamente los errores de todos modos.

Varias configuraciones serían geniales. Estoy trabajando en un proyecto React-Native y básicamente tengo dos compilaciones que quiero hacer:

1. los scripts de mi proyecto React-Native
2. los scripts utilizados en el HTML para los WebViews React-Native (gráficos).

La herencia de configuración se ha agregado en TS 2.1 y debería estar disponible en typescript@next hoy. consulte https://github.com/Microsoft/TypeScript/issues/9876 para obtener más detalles. Con eso, puede tener un tsconfig.json "maestro" y anular los que heredan configuraciones de él. todavía necesita crear varios archivos tsconfig.json, pero su IDE debería recogerlos.

Tengo la siguiente estructura de directorio:

├── examples
│   ├── files...
│   └── tsconfig.json
├── src
│   └──files...
└── tsconfig.json

Raíz tsconfig.json tiene:

{
  "compilerOptions": {
    "target": "es2015",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "dist",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": false,
    "noImplicitAny": false,
    "declaration": true,
    "allowJs": false
  },
  "include": [
    "./src"
  ],
  "compileOnSave": false,
  "buildOnSave": false,
  "atom": { "rewriteTsconfig": false }
}

examples/tsconfig.json tienen el mismo valor excepto:

  "include": [
    "./hello-world"
  ],

Cuando lo hago:

cd examples
tsc

Compila:

├── examples
│   ├── dist
│   │   ├── examples
│   │   └── src
│   ├── files...
│   └── tsconfig.json
├── src
│   └──  files...
└── tsconfig.json

( dist incorrecto incluye la carpeta externa src y se compila desde la carpeta raíz)

No ayuda con esto (en examples/tsconfig.json ):

  "exclude": [
    "../src"
  ],

¿Qué estoy haciendo mal?

Encontré un problema. Si en mi examples/hello-world/any-file*.ts esta importación:

import { SomeClass } from '../../src';

Es el problema descrito anteriormente. La siguiente importación funciona como se esperaba:

import { SomeClass } from '../../';

Pero, ¿por qué la directiva de mecanografiado include no funciona como se esperaba?

No puedo hacer que funcione
Insiste en " Advertencia: no se puede encontrar el tsconfig.json principal" aunque tengo tsconfig.json en la misma carpeta, no sé qué hacer con esto

@zhukovka por favor registre un nuevo problema con una reproducción independiente que podamos ejecutar localmente

@RyanCavanaugh Oh. gracias, lo he descubierto
el problema se reproduce solo si tengo un archivo abierto desde una carpeta de prueba (que no incluía tsconfig.json) y el segundo archivo abierto en una carpeta 'src' (que incluía tsconfig.json)
y el archivo de la carpeta de prueba importa el de la carpeta src. En este caso, el archivo de la carpeta src no ve su 'tsconfig.json principal'

@RyanCavanaugh , el soporte para compilar con varios tsconfig.json diferentes parece continuar siendo algo que a los desarrolladores les gustaría tener. Para mis casos, generalmente se trata de cambiar dónde van los archivos de salida generados. Parece que si las generaciones de código pudieran ser controladas por algo como el mapeo paths que me permite diseñar mi código generado de manera diferente a las fuentes, tal vez se reduciría la necesidad de múltiples proyectos.

Mi caso de uso es que tengo una gran base de código heredada que no puede soportar las reglas de verificación de tipo más estrictas, y quiero usarla en una nueva base de código que _tiene_ verificaciones estrictas habilitadas, y no puedo compilar el código heredado en un biblioteca porque tiene un millón de casos en los que no importa todos los tipos necesarios para nombrar los tipos para sus exportaciones (# 9944). Así que solo quiero agregar la base de código heredada a la nueva base de código, pero compilado de acuerdo con reglas más laxas. Estos no pueden ser 2 pasos de compilación diferentes; justo cuando el compilador está trabajando en archivos fuente en un directorio determinado, debería usar reglas más laxas.

Para mí, el caso de uso es tener parte del repositorio que se ejecuta con el nodo y debe compilarse en módulos commonjs, mientras que la otra parte debe compilarse en módulos ES6 para habilitar el cambio de árbol en ES6. La experiencia no es muy buena, hay mucho pirateo con las variables de entorno TS_NODE_PROJECT , en mi caso. Definitivamente parece algo que podría confundir muchísimo a la próxima persona que lo mantenga cuando eventualmente cambie de proyecto.

Todavía me encantaría ver esto resuelto. Sería una gran ganancia para proyectos más grandes que requieren diferentes archivos tsconfig.json por módulo dentro de un proyecto.

@Robinfr, ¿qué no te resuelve la función extends ?

Lo hizo. Me enteré de eso después de esta publicación. Sin embargo, una cosa a tener en cuenta es que no funcionó sin configurar include en los archivos que, por lo general, k no tienen que hacerlo ya que pasan por el paquete web.

Op. 15 sep. 2017 9:24 am schreef Kitson Kelly [email protected] :

@Robinfr https://github.com/robinfr lo que hace la función extiende https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends no resuelve para usted?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yawlC1oTIksJc8wiiZ .

La extensión de TS_NODE_PROJECT . El otro es cuando se abre un proyecto con dos tsconfigs en VS.code. No hay forma (que yo sepa) de decirle a VS qué archivo de proyecto usar y eso significa que para algunos archivos los errores no se subrayarán correctamente, debido a las diferentes configuraciones para esos archivos en el tsconfig correspondiente (digamos, algo como tsconfig.build.json).

@voy , ¿puedo preguntar por qué tiene un tsconfig diferente para construir? Por lo que tengo entendido, VSCode usa el archivo tsconfig más cercano ( tsconfig.json ) al archivo que está editando. El único problema que he tenido hasta ahora es que necesita tener un archivo tsconfig en la raíz antes de que VSCode parezca comenzar a usar las configuraciones ...

@Robinfr seguro. en el mismo repositorio tengo archivos que se procesan usando webpack & babel y usan módulos ES6 para permitir la agitación de árboles. otros archivos son parte del proceso de compilación y se ejecutan usando node, por lo que las importaciones deben transpilarse a require. No estoy seguro de cómo podría solucionarlo.

@voy, ¿no tendrías esos archivos en una carpeta separada? Por ejemplo, 1 carpeta para todos los archivos de Babel y webpack, y 1 para los archivos de nodo. Entonces puede tener un tsconfig.json para cada una de esas carpetas. ¿No funcionaría eso para ti?

@Robinfr eso sería ideal, pero creo que no siempre es posible en el mundo real. por ejemplo, queremos que todos nuestros archivos de configuración también sean mecanografiados, compilados y enlazados de acuerdo con las mismas reglas que todo el código base de TypeScript y algunos archivos deben estar en la raíz del proyecto. podría enlazar simbólicamente, pero eso a veces trae otros problemas. por eso siento que algo más flexible sería un beneficio.