Typescript: Suporte para vários tsconfig.json por projeto

Criado em 26 jun. 2015  ·  37Comentários  ·  Fonte: microsoft/TypeScript

Oi! É possível usar vários tsconfig.json por projeto, ou seja, algum tipo de tsconfig.json em todo o projeto localizado no diretório raiz e tsconfig.json arquivos adicionais localizados em subdiretórios que podem substituir / tune algumas opções para esses dirs? Como .gitignore faz.

Seria muito útil quando, por exemplo, desenvolver um módulo externo em node -ambiente. Esses módulos geralmente são divididos em vários arquivos (módulos internos), mas seriam compilados em um grande arquivo durante o estágio de compilação.

Question

Comentários muito úteis

Finalmente consigo a solução.

minha estrutura de aplicativo:
-- aplicativo/- app / client / (meu código-fonte do lado do cliente)- app / server / (código-fonte do meu servidor)- app / build / (onde eu gero o js)- app / node-modules /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

Conteúdo de tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"exclude": ["node_modules", "client"]}

Conteúdo de tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"exclude": ["node_modules", "server"]}


Então, quando eu quero compilar o código-fonte do servidor, uso este comando do diretório raiz do aplicativo:

tsc --p tsconfig.server.json


E para compilar o código-fonte do cliente, também do diretório raiz do aplicativo:

tsc --p tsconfig.client.json


Para executar a compilação do cliente e do servidor, adicionei um comando em package.json:

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

Em seguida, para compilar o servidor e o cliente, acabei de executar isso do diretório raiz do meu aplicativo:

npm run tsc

Espero que este comentário possa ajudá-lo :-)

Todos 37 comentários

Ei @lazutkin. Atualmente não há suporte para isso, embora eu queira apenas vincular esse problema ao # 2869 porque está relacionado.

O compilador escolhe o tsconfig.json mais próximo da pasta que você está construindo, se você estiver executando tsc sem argumentos em uma pasta. portanto, se você tiver um diretório interno com um tsconfig.json, ele será selecionado antes do diretório externo.

Não acho que iremos oferecer suporte à integração / configuração de substituição de vários tsconfig.json.

Vários arquivos tsconfig são indispensáveis ​​para aplicativos de grandes empresas.
Sugestão: Sempre que tsc encontra um novo arquivo tsconfig em um subdiretório, tsc para aqui e cria um novo processo tsc com seu próprio arquivo tsconfig.

@Eisenspalter isso soa como um trabalho de driver de construção, algo como grunt, gulp ou msbuild.

@mhegazy Concordo com @Eisenspalter porque ambos falamos não sobre o processo de construção, mas sobre o processo de desenvolvimento, incluindo a escrita de fontes, testes e outras atividades que precisamos concluir antes da construção. Em todas essas etapas intermediárias, precisamos ter suporte de typescript incluindo intellisense, verificação de tipos etc. Além disso, como eu disse antes, para diferentes partes do projeto, gostaríamos de aplicar diferentes técnicas de organização de fonte (módulos externos-internos, individuais arquivo de saída, etc) e aqui precisamos que algumas opções sejam substituídas por tsconfig separado.

@mhegazy Por que fechado? Abra novamente.

você pode ter vários tsconfig hoje, cada um apontando para um conjunto de arquivos sobrepostos. então, um em srctsconfig.json, um em teststsconfig.json, etc. o compilador / ferramentas irá localizar o arquivo subindo na árvore de diretórios para encontrar o mais próximo. então você pode ter um terceiro arquivo na raiz para capturar todos.

Isso tudo funciona hoje, no compilador e nos diferentes IDEs. o problema original era permitir que um arquivo herdasse de outro. não acho que haja valor suficiente para justificar a complexidade.

Para o segundo problema:

Sempre que o tsc encontra um novo arquivo tsconfig em um subdiretório, o tsc para aqui e cria um novo processo tsc com seu próprio arquivo tsconfig.

Como mencionei anteriormente, um tsconfig.json representa uma única invocação para tsc.js / tsc.exe. Se você quiser fazer várias invocações, deverá usar um driver de compilação.

@lazutkin e @Eisenspalter respondem às perguntas

@mhegazy
Não foi possível fazer com que vários tsconfig.json funcionassem. Pelo menos com TypeScript 1.7.3, apenas um tsconfig.json é lido e espera-se que esteja no diretório raiz (ou pai) do projeto.

@Ziink meu comentário acima não era sobre vários tsconfigs no mesmo projeto. tratava-se de vários projetos / diretórios, cada um com um tsconfig diferente. é assim que o projeto ts é organizado, consulte https://github.com/Microsoft/TypeScript/tree/master/src , cada pasta em src tem um tsconfig.json diferente

Tenho um projeto escrito em TypeScript e desejo atingir ambos:

  1. navegador (digamos arquivos em /browser ) com ES5 / AMD e
  2. nodejs (arquivos em server ) com CommonJS e geradores (e async / await no TS).

Existem alguns arquivos compartilhados, digamos, na pasta ( /common ) e há importações de common para browser e server .
Como posso conseguir tal configuração preservando o suporte IDE, todos os erros etc? Não tenho certeza se a discussão respondeu às minhas dúvidas.

@bartq Com o TS 1.8, eu criaria dois arquivos tsconfig, um para o navegador e um para o servidor, e adicionaria referências /// em seus arquivos em ambos os subprojetos aos comuns. experimente e diga-nos se isso resolve o cenário ou se ainda faltam peças.

na verdade, estou usando esses dois tsconfig.json arquivos, o WebStorm os descobre e executa a compilação automaticamente. Para ser preciso, o código de back-end importa algumas classes do código de front-end (em vez de usar o conceito common ), mas tudo funciona bem.

Finalmente consigo a solução.

minha estrutura de aplicativo:
-- aplicativo/- app / client / (meu código-fonte do lado do cliente)- app / server / (código-fonte do meu servidor)- app / build / (onde eu gero o js)- app / node-modules /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

Conteúdo de tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"exclude": ["node_modules", "client"]}

Conteúdo de tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"exclude": ["node_modules", "server"]}


Então, quando eu quero compilar o código-fonte do servidor, uso este comando do diretório raiz do aplicativo:

tsc --p tsconfig.server.json


E para compilar o código-fonte do cliente, também do diretório raiz do aplicativo:

tsc --p tsconfig.client.json


Para executar a compilação do cliente e do servidor, adicionei um comando em package.json:

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

Em seguida, para compilar o servidor e o cliente, acabei de executar isso do diretório raiz do meu aplicativo:

npm run tsc

Espero que este comentário possa ajudá-lo :-)

Não entendo qual é o problema aqui. Por que não podemos oferecer suporte a configurações com nomes de arquivo diferentes? É uma dor ter que criar subpastas APENAS para ter um arquivo tsconfig diferente.

Você pode. --p argumento ca é um nome de arquivo.

Os diferentes nomes de arquivo não funcionam com a extensão do compilador de texto digitado do Visual Studio (não falando sobre CLI) fora da caixa. A única maneira de fazer isso é colocar cada tsconfig.json em um diretório fictício e ter um link de volta para os scripts de digitação que você deseja com a opção files .

por exemplo

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

target / search / tsconfig.json seria algo como:

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

E os outros seriam semelhantes.

Isso produziria 3 arquivos javascript, cada um com sua própria configuração de arquivos, agrupados em um.

Claro, você poderia usar uma solução diferente de empacotamento / minimização / empacotamento do que o próprio compilador Typescript.

O problema é que o compilador Typescript faz um trabalho muito bom com a otimização - essa é uma das maiores vantagens do uso do Typescript.

Portanto, seria bom se um único tsconfig.json pudesse oferecer suporte a várias configurações apenas alterando-o para ser uma 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
  }
]

Isso é o que parece estar sendo solicitado nos comentários posteriores deste problema, embora eu concorde, o problema original era mais sobre herança e configurações de substituição.

@mhegazy @bartq Não consigo fazer funcionar com o comando tsc .
Eu tenho a seguinte estrutura de diretório

-- 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

No entanto, quando executo tsc apenas a configuração de app/tsconfig.json é usada, o resto é ignorado. Estou tentando fazer funcionar em VSCode: /

@tomitrescak Estou usando o WebStorm e ele é inteligente o suficiente para encontrar o tsconfig.json mais próximo e usá-lo ao editar um arquivo. Provavelmente não há nenhuma ferramenta cmd que suporte assistir a múltiplos tsconfig.json's. Você pode implementá-lo usando, por exemplo, o guarda FB.

Sim, adoraria ter algo assim no VS Code. Estou executando a compilação no terminal. Funciona também. O VS Code identifica corretamente os erros de qualquer maneira.

Múltiplas configurações seriam ótimas. Estou trabalhando em um projeto React-Native e basicamente tenho duas compilações que quero fazer:

  1. os scripts do meu projeto React-Native
  2. os scripts usados ​​no HTML para React-Native WebViews (gráficos).

A herança da configuração foi adicionada ao TS 2.1 e deve estar disponível em typescript@next hoje. consulte https://github.com/Microsoft/TypeScript/issues/9876 para obter mais detalhes. Com isso, você pode ter um tsconfig.json "mestre" e substituir aqueles que herdam as configurações dele. você ainda precisa criar vários arquivos tsconfig.json, mas seu IDE deve pegá-los.

Tenho a seguinte estrutura de diretório:

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

Root tsconfig.json tem:

{
  "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 têm o mesmo valor, exceto:

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

Quando eu faço:

cd examples
tsc

Compila:

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

( dist errado inclui a pasta externa src e compila a partir da pasta raiz)

Não ajuda nisso (em examples/tsconfig.json ):

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

O que estou fazendo errado?

Eu encontrei o problema. Se em minha examples/hello-world/any-file*.ts esta importação:

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

É o problema descrito acima. A importação a seguir funciona conforme o esperado:

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

Mas por que a diretiva include do typescript não funciona conforme o esperado?

Não consigo fazer funcionar
Ele insiste em " Aviso: Não é possível encontrar o pai tsconfig.json" embora eu tenha tsconfig.json na mesma pasta, não sei o que fazer com isso

@zhukovka , registre um novo problema com uma reprodução autônoma que podemos executar localmente

@RyanCavanaugh Oh. obrigado, eu descobri
o problema é reproduzido apenas se eu tiver um arquivo aberto em uma pasta de teste (que não inclui tsconfig.json) e o segundo arquivo aberto em uma pasta 'src' (que inclui tsconfig.json)
e o arquivo da pasta de teste importa o da pasta src. Neste caso, o arquivo da pasta src não vê seu 'pai tsconfig.json'

@RyanCavanaugh , o suporte para compilar com vários tsconfig.json diferentes parece continuar sendo algo que os desenvolvedores gostariam de ter. Para meus casos, geralmente se trata de alterar para onde vão os arquivos de saída gerados. Parece que se as gerações de código pudessem ser controladas por algo como o mapeamento paths permitindo-me fazer o layout do meu código gerado de forma diferente das fontes, talvez a necessidade de vários projetos fosse diminuída.

Meu caso de uso é que eu tenho uma grande base de código legada que não pode suportar as regras de verificação de tipo mais rígidas e quero usá-la em uma nova base de código que _têm_ verificações rígidas habilitadas e não consigo compilar o código legado para um biblioteca porque tem um milhão de casos em que não importa todos os tipos necessários para nomear os tipos de suas exportações (# 9944). Portanto, quero apenas adicionar a base de código legada à nova base de código, mas compilada de acordo com regras mais flexíveis. Isso não pode ser 2 etapas de compilação diferentes; apenas quando o compilador está trabalhando em arquivos de origem em um determinado diretório, ele deve estar usando as regras mais flexíveis.

Para mim, o caso de uso é ter parte do repo que é executado usando o nó e precisa ser compilado para módulos commonjs, enquanto a outra parte precisa ser compilada para módulos ES6 para habilitar o treehaking no ES6. A experiência não é ótima, há muito hackeando com TS_NODE_PROJECT variáveis ​​de ambiente, no meu caso. Definitivamente parece algo que poderia confundir a próxima pessoa que o manteria quando eu eventualmente mudasse de projeto.

Eu ainda adoraria ver isso resolvido. Seria uma grande vitória para projetos maiores que requerem diferentes tsconfig.json arquivos por módulo dentro de um projeto.

@Robinfr, o que o recurso extends não resolve para você?

Sim. Eu descobri sobre isso depois desse post. Uma coisa a se notar, no entanto, é que não funcionou sem definir include para os arquivos, o que k normalmente não precisa, pois passa pelo webpack.

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

@Robinfr https://github.com/robinfr o que o recurso de extensão https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends não resolve para você?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706 ou desative o tópico https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yawlC1oTIks5FgaT_yawlC1oTIks5FgaFs5 .

A extensão do TS_NODE_PROJECT . A outra é ao abrir um projeto com dois tsconfigs em VS.code. Não há nenhuma maneira (que eu saiba) de dizer ao VS qual arquivo de projeto usar e isso significa que, para alguns arquivos, os erros não serão sublinhados corretamente, devido a configurações diferentes para esses arquivos no tsconfig correspondente (digamos, algo como tsconfig.build.json).

@voy, posso perguntar por que você tem um tsconfig diferente para construção? Pelo que entendi, o VSCode usa o arquivo tsconfig mais próximo ( tsconfig.json ) ao arquivo que você está editando. O único problema que tive até agora é que você precisa ter um arquivo tsconfig na raiz antes que o VSCode comece a usar as configurações ...

@Robinfr certeza. no mesmo repositório, tenho arquivos que são processados ​​usando webpack & babel e usam módulos ES6 para ativar a agitação de árvores. outros arquivos fazem parte do processo de construção e são executados usando o nó, razão pela qual as importações precisam ser transpiladas para os requer. não tenho certeza de como eu poderia contornar isso.

@voy , você não teria apenas esses arquivos em uma pasta separada? Por exemplo, 1 pasta para todos os arquivos Babel e webpack e 1 para os arquivos de nó. Então você pode apenas ter um tsconfig.json para cada uma dessas pastas. Isso não funcionaria para você?

@Robinfr isso seria o ideal, mas acho que nem sempre é possível no mundo real. por exemplo, queremos que todos os nossos arquivos de configuração também sejam digitados, compilados e lintados de acordo com as mesmas regras de todas as bases de código do TypeScript e alguns arquivos devem estar na raiz do projeto. você poderia criar um link simbólico, mas isso às vezes traz outros problemas. é por isso que acho que algo mais flexível seria um benefício.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

DanielRosenwasser picture DanielRosenwasser  ·  3Comentários

jbondc picture jbondc  ·  3Comentários

fwanicka picture fwanicka  ·  3Comentários

manekinekko picture manekinekko  ·  3Comentários

wmaurer picture wmaurer  ·  3Comentários