Typescript: Prise en charge de plusieurs tsconfig.json par projet

CrĂ©Ă© le 26 juin 2015  Â·  37Commentaires  Â·  Source: microsoft/TypeScript

Salut! Est-il possible d'utiliser plusieurs tsconfig.json par projet, c'est-à-dire une sorte de tsconfig.json à l'échelle du projet situé dans le répertoire racine et des fichiers tsconfig.json supplémentaires situés dans des sous-répertoires qui peuvent remplacer / régler certaines options pour ces répertoires? Comme le fait .gitignore .

Ce serait trÚs utile lorsque, par exemple, développer un module externe sous node -environment. Ces modules sont généralement divisés en plusieurs fichiers (modules internes), mais seraient compilés en un seul gros fichier pendant la phase de compilation.

Question

Commentaire le plus utile

J'ai enfin la solution.

ma structure d'application:
- application /- app / client / (mon code source cĂŽtĂ© client)- app / server / (mon code source cĂŽtĂ© serveur)- app / build / (oĂč je gĂ©nĂšre les js)- app / modules-nƓuds /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

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

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


Ensuite, lorsque je veux compiler le code source du serveur, j'utilise cette commande à partir du répertoire racine de l'application:

tsc --p tsconfig.server.json


Et pour compiler le code source du client, également à partir du répertoire racine de l'application:

tsc --p tsconfig.client.json


Afin d'exécuter à la fois la compilation client et serveur, j'ai ajouté une commande dans package.json:

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

Ensuite, pour compiler à la fois le serveur et le client, je l'exécute simplement à partir du répertoire racine de mon application:

npm exécuter tsc

J'espĂšre que ce commentaire pourra vous aider :-)

Tous les 37 commentaires

Salut @lazutkin. Actuellement, ce n'est pas pris en charge, bien que je souhaite simplement lier ce problÚme à # 2869 car il est quelque peu lié.

Le compilateur sélectionne le tsconfig.json le plus proche du dossier que vous créez si vous exécutez tsc sans arguments dans un dossier. donc si vous avez un répertoire interne avec un tsconfig.json, il sera récupéré avant celui du répertoire externe.

Je ne pense pas que nous prendrons en charge l'intégration / la configuration de remplacement à partir de plusieurs tsconfig.json.

Plusieurs fichiers tsconfig sont indispensables pour les grandes applications d'entreprise.
Suggestion: chaque fois que tsc trouve un nouveau fichier tsconfig dans un sous-rĂ©pertoire, tsc s'arrĂȘte ici et crĂ©e un nouveau processus tsc avec son propre fichier tsconfig.

@Eisenspalter cela ressemble Ă  un travail de pilote de construction, quelque chose comme grunt, gulp ou msbuild.

@mhegazy Je suis d'accord avec @Eisenspalter car nous ne parlons pas tous les deux de processus de construction mais de processus de dĂ©veloppement, y compris l'Ă©criture des sources, les tests et d'autres activitĂ©s que nous devons terminer avant la construction. Sur toutes ces Ă©tapes intermĂ©diaires, nous devons avoir le support de typescript y compris intellisense, typechecking etc. De plus, comme je l'ai dĂ©jĂ  dit, pour diffĂ©rentes parties du projet, nous aimerions appliquer diffĂ©rentes techniques d'organisation des sources (modules externes-internes, simples fichier de sortie, etc.) et ici nous avons besoin de certaines options pour ĂȘtre remplacĂ©es par tsconfig sĂ©parĂ©.

@mhegazy Pourquoi fermé? Veuillez rouvrir.

vous pouvez avoir plusieurs tsconfig aujourd'hui, chacun pointant vers un ensemble de fichiers qui se chevauchent. donc un dans srctsconfig.json, un dans teststsconfig.json, etc. le compilateur / tools localisera le fichier en parcourant l'arborescence des répertoires pour trouver le plus proche. vous pouvez donc avoir un troisiÚme fichier à la racine pour tout attraper.

Tout cela fonctionne aujourd'hui, dans le compilateur et les différents IDE. le problÚme initial consistait à autoriser un fichier à hériter d'un autre. je ne pense pas qu'il y ait suffisamment de valeur là-bas justifie la complexité.

Pour le deuxiÚme numéro:

Chaque fois que tsc trouve un nouveau fichier tsconfig dans un sous-rĂ©pertoire, tsc s'arrĂȘte ici et crĂ©e un nouveau processus tsc avec son propre fichier tsconfig.

Comme je l'ai mentionné précédemment, un tsconfig.json représente une seule invocation à tsc.js / tsc.exe si vous voulez faire plusieurs invocations, vous devez utiliser un pilote de construction.

@lazutkin et @Eisenspalter répondent-ils aux questions

@mhegazy
Impossible de faire fonctionner plusieurs tsconfig.json. Au moins avec TypeScript 1.7.3, un seul tsconfig.json est lu et devrait se trouver dans le répertoire racine (ou parent) du projet.

@Ziink mon commentaire ci-dessus ne concernait pas plusieurs tsconfigs dans le mĂȘme projet. il s'agissait de plusieurs projets / rĂ©pertoires, chacun avec un tsconfig diffĂ©rent. voici comment le projet ts est prĂ©sentĂ©, voir https://github.com/Microsoft/TypeScript/tree/master/src , chaque dossier sous src a un tsconfig.json diffĂ©rent

J'ai un projet Ă©crit en TypeScript et je souhaite cibler les deux:

  1. navigateur (disons des fichiers dans /browser ) avec ES5 / AMD et
  2. nodejs (fichiers dans server ) avec CommonJS et générateurs (et async / await dans TS).

Il y a des fichiers partagés, disons dans le dossier ( /common ) et il y a des importations de common vers browser et server .
Comment puis-je obtenir une telle configuration en préservant le support IDE, toutes les erreurs, etc.? Je ne sais pas si la discussion a répondu à mes doutes.

@bartq Avec TS 1.8, je créerais deux fichiers tsconfig, un pour le navigateur et un pour le serveur, et ajouterais des références /// dans vos fichiers dans les deux sous-projets aux plus communs. essayez-le et faites-nous savoir si cela répond au scénario ou s'il manque encore des piÚces.

en fait, j'utilise ces deux fichiers tsconfig.json , WebStorm les dĂ©couvre et exĂ©cute la compilation automatiquement. Pour ĂȘtre prĂ©cis, le code backend importe des classes Ă  partir du code frontend (Ă  la place en utilisant le concept common ), mais tout fonctionne bien.

J'ai enfin la solution.

ma structure d'application:
- application /- app / client / (mon code source cĂŽtĂ© client)- app / server / (mon code source cĂŽtĂ© serveur)- app / build / (oĂč je gĂ©nĂšre les js)- app / modules-nƓuds /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

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

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


Ensuite, lorsque je veux compiler le code source du serveur, j'utilise cette commande à partir du répertoire racine de l'application:

tsc --p tsconfig.server.json


Et pour compiler le code source du client, également à partir du répertoire racine de l'application:

tsc --p tsconfig.client.json


Afin d'exécuter à la fois la compilation client et serveur, j'ai ajouté une commande dans package.json:

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

Ensuite, pour compiler à la fois le serveur et le client, je l'exécute simplement à partir du répertoire racine de mon application:

npm exécuter tsc

J'espĂšre que ce commentaire pourra vous aider :-)

Je ne comprends pas quel est le problÚme ici. Pourquoi ne pouvons-nous pas prendre en charge les configurations avec des noms de fichiers différents? C'est une douleur d'avoir à créer des sous-dossiers JUSTE pour avoir un fichier tsconfig différent.

Vous pouvez. L'argument --p peut ĂȘtre un nom de fichier.

Les différents noms de fichiers ne fonctionneront pas avec l'extension de compilateur Visual Studio typescript (sans parler de CLI) par défaut. Le seul moyen de le faire est de mettre chaque tsconfig.json dans un répertoire factice et de le renvoyer aux scripts de saisie souhaités avec l'option files .

par exemple

--src / cible / recherche / tsconfig.json
--src / target / core / tsconfig.json
--src / target / users / tsconfig.json

target / search / tsconfig.json ressemblerait Ă  quelque chose comme:

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

Et les autres seraient similaires.

Cela produirait 3 fichiers javascript, chacun avec sa propre configuration de fichiers, regroupés en un seul.

Bien sĂ»r, vous pouvez utiliser une solution de regroupement / minimisation / empaquetage diffĂ©rente de celle du compilateur Typescript lui-mĂȘme.

C'est juste que le compilateur Typescript fait un trĂšs bon travail avec l'optimisation - c'est l'un des plus gros attraits de l'utilisation de Typescript.

Donc, ce serait bien si un seul tsconfig.json pouvait prendre en charge plusieurs configurations en le changeant simplement en un tableau 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
  }
]

C'est ce Ă  quoi cela ressemble d'ĂȘtre demandĂ© dans les commentaires ultĂ©rieurs de ce problĂšme, bien que je sois d'accord, le problĂšme original concernait davantage l'hĂ©ritage et les configurations de remplacement.

@mhegazy @bartq Je ne peux pas le faire fonctionner avec la commande tsc .
J'ai une structure de répertoires suivante

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

Pourtant, lorsque j'exécute tsc seule la configuration de app/tsconfig.json est utilisée, le reste est ignoré. J'essaye de le faire fonctionner en VSCode: /

@tomitrescak J'utilise WebStorm et il est suffisamment intelligent pour trouver le tsconfig.json le plus proche et l'utiliser lorsque vous éditez un fichier. Il n'y a probablement aucun outil cmd qui prend en charge l'observation de plusieurs tsconfig.json. Vous pouvez le déployer en utilisant par exemple FB watchman.

Ouais, j'aimerais avoir quelque chose comme ça dans VS Code. J'exécute la compilation dans le terminal. Fonctionne aussi. VS Code identifie correctement les erreurs de toute façon.

Plusieurs configurations seraient géniales. Je travaille sur un projet React-Native et j'ai essentiellement deux builds que je veux faire:

  1. les scripts de mon projet React-Native
  2. les scripts utilisés dans le HTML pour les WebViews React-Native (graphiques).

L'hĂ©ritage de configuration a Ă©tĂ© ajoutĂ© dans TS 2.1 et devrait ĂȘtre disponible dans typescript@next aujourd'hui. voir https://github.com/Microsoft/TypeScript/issues/9876 pour plus de dĂ©tails. Avec cela, vous pouvez avoir un tsconfig.json "maĂźtre" et remplacer ceux qui en hĂ©ritent des configurations. vous devez toujours crĂ©er plusieurs fichiers tsconfig.json, mais votre IDE devrait les rĂ©cupĂ©rer.

J'ai une structure de répertoires suivante:

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

Root tsconfig.json a:

{
  "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 ont la mĂȘme valeur sauf:

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

Quand je fais:

cd examples
tsc

Il compile:

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

( dist mauvais inclut le dossier externe src et compile Ă  partir du dossier racine)

Pas aider ça (en examples/tsconfig.json ):

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

Qu'est-ce que je fais mal?

J'ai trouvé un problÚme. Si dans mon examples/hello-world/any-file*.ts cette importation:

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

C'est le problÚme décrit ci-dessus. L'importation suivante fonctionne comme prévu:

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

Mais pourquoi la directive de type include ne fonctionne pas comme prévu?

Je ne peux pas le faire fonctionner
Il insiste sur " Avertissement: Impossible de trouver le parent tsconfig.json" bien que j'ai tsconfig.json dans le mĂȘme dossier, je ne sais pas quoi faire avec cela

@zhukovka veuillez enregistrer un nouveau problÚme avec une reproduction autonome que nous pouvons exécuter localement

@RyanCavanaugh Oh. merci, je l'ai compris
le problĂšme se reproduit uniquement si j'ai un fichier ouvert Ă  partir d'un dossier de test (qui n'incluait pas tsconfig.json) et le deuxiĂšme fichier ouvert dans un dossier 'src' (qui incluait tsconfig.json)
et le fichier du dossier de test importe celui du dossier src. Dans ce cas, le fichier du dossier src ne voit pas son 'parent tsconfig.json'

@RyanCavanaugh , la prise en charge de la compilation avec plusieurs tsconfig.json semble continuer Ă  ĂȘtre quelque chose que les dĂ©veloppeurs aimeraient avoir. Dans mon cas, il s'agit gĂ©nĂ©ralement de changer l'emplacement des fichiers de sortie gĂ©nĂ©rĂ©s. Il semble que si les gĂ©nĂ©rations de code pouvaient ĂȘtre contrĂŽlĂ©es par quelque chose comme le mappage paths existant me permettant de mettre en page mon code gĂ©nĂ©rĂ© diffĂ©remment des sources, peut-ĂȘtre que le besoin de plusieurs projets serait rĂ©duit.

Mon cas d'utilisation est que j'ai une grande base de code hĂ©ritĂ©e qui ne peut pas rĂ©sister aux rĂšgles de vĂ©rification de type plus strictes, et je veux l'utiliser dans une nouvelle base de code qui _does_ a des vĂ©rifications strictes activĂ©es, et je ne peux pas compiler le code hĂ©ritĂ© en un bibliothĂšque car elle a un million de cas oĂč elle n'importe pas tous les types requis pour nommer les types pour ses exportations (# 9944). Je veux donc simplement ajouter la base de code hĂ©ritĂ©e Ă  la nouvelle base de code, mais compilĂ©e selon des rĂšgles plus laxistes. Cela ne peut pas ĂȘtre 2 Ă©tapes de compilation diffĂ©rentes; juste quand le compilateur travaille sur des fichiers source dans un certain rĂ©pertoire, il devrait utiliser les rĂšgles laxer.

Pour moi, le cas d'utilisation est d'avoir une partie du rĂ©fĂ©rentiel qui est exĂ©cutĂ©e Ă  l'aide de node et doit ĂȘtre compilĂ©e en modules commonjs, tandis que l'autre partie doit ĂȘtre compilĂ©e en modules ES6 afin d'activer le treehaking dans ES6. L'expĂ©rience n'est pas gĂ©niale, il y a beaucoup de piratage avec des variables d'environnement TS_NODE_PROJECT , dans mon cas. Cela semble dĂ©finitivement ĂȘtre quelque chose qui pourrait dĂ©router la personne suivante qui le maintiendrait lorsque je changerai Ă©ventuellement de projet.

J'adorerais toujours voir cela résolu. Ce serait une énorme victoire pour les projets plus importants qui nécessitent différents fichiers tsconfig.json par module au sein d'un projet.

@Robinfr qu'est-ce que la fonctionnalité extends ne résout pas pour vous?

Ça faisait. J'ai dĂ©couvert cela aprĂšs ce post. Une chose Ă  noter cependant est que cela n'a pas fonctionnĂ© sans dĂ©finir le include sur les fichiers que k n'a gĂ©nĂ©ralement pas Ă  faire car il passe par webpack.

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

@Robinfr https://github.com/robinfr ce qui ne l'étend fonction https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends ne résoudra pas pour vous?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yJksFiiM8o .

L' extension TS_NODE_PROJECT . L'autre est lors de l'ouverture d'un projet avec deux tsconfigs dans VS.code. Il n'y a aucun moyen (à ma connaissance) de dire à VS quel fichier de projet utiliser et cela signifie que pour certains fichiers, les erreurs ne seront pas correctement soulignées, en raison de paramÚtres différents pour ces fichiers dans le tsconfig correspondant (par exemple, quelque chose comme tsconfig.build.json).

@voy puis-je vous demander pourquoi vous avez un tsconfig différent pour la construction? Autant que je sache, VSCode utilise le fichier tsconfig le plus proche ( tsconfig.json ) du fichier que vous éditez. Le seul problÚme que j'ai eu jusqu'à présent est que vous devez avoir un fichier tsconfig à la racine avant que VSCode ne semble commencer à utiliser les configurations ...

@Robinfr sĂ»r. dans le mĂȘme rĂ©fĂ©rentiel, j'ai des fichiers qui sont traitĂ©s Ă  l'aide de webpack & babel et utilisent des modules ES6 pour activer le tremblement d'arbre. d'autres fichiers font partie du processus de construction et sont exĂ©cutĂ©s Ă  l'aide de node, c'est pourquoi les importations doivent ĂȘtre transpilĂ©es en requires. Je ne sais pas comment je pourrais contourner cela.

@voy n'auriez-vous pas simplement ces fichiers dans un dossier sĂ©parĂ©? Par exemple, 1 dossier pour tous les fichiers Babel & webpack, et 1 pour les fichiers de nƓuds. Ensuite, vous pouvez simplement avoir un tsconfig.json pour chacun de ces dossiers. Cela ne fonctionnerait-il pas pour vous?

@Robinfr ce serait idĂ©al, mais je pense que ce n'est pas toujours possible dans le monde rĂ©el. par exemple, nous voulons que tous nos fichiers de configuration soient Ă©galement dactylographiĂ©s, compilĂ©s et lintĂ©s selon les mĂȘmes rĂšgles que l'ensemble de la base de code TypeScript et certains fichiers doivent ĂȘtre Ă  la racine du projet. vous pouvez crĂ©er un lien symbolique, mais cela soulĂšve parfois d'autres problĂšmes. c'est pourquoi je pense que quelque chose de plus flexible serait un avantage.

Cette page vous a été utile?
0 / 5 - 0 notes