Typescript: Unterstützung für mehrere tsconfig.json pro Projekt

Erstellt am 26. Juni 2015  ·  37Kommentare  ·  Quelle: microsoft/TypeScript

Hallo! Ist es möglich, mehrere tsconfig.json pro Projekt zu verwenden, dh eine Art projektweites tsconfig.json im Stammverzeichnis und zusätzliche tsconfig.json Dateien in Unterverzeichnissen, die möglicherweise überschrieben werden Ich stimme einige Optionen für diese Verzeichnisse? Wie .gitignore .

Es wäre sehr nützlich, wenn Sie beispielsweise ein externes Modul unter einer Umgebung von node würden. Solche Module werden normalerweise in mehrere Dateien (interne Module) aufgeteilt, aber während der Kompilierungsphase in eine große Datei kompiliert.

Question

Hilfreichster Kommentar

Ich bekomme endlich die Lösung.

meine Bewerbungsstruktur:
- App /- app / client / (mein clientseitiger Quellcode)- app / server / (mein serverseitiger Quellcode)- app / build / (wo ich das js generiere)- App / Knotenmodule /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

Inhalt von tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"ausschließen": ["node_modules", "client"]}

Inhalt von tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"ausschließen": ["Knotenmodule", "Server"]}


Wenn ich dann Server-Quellcode kompilieren möchte, verwende ich diesen Befehl aus dem App-Stammverzeichnis:

tsc --p tsconfig.server.json


Und um Client-Quellcode zu kompilieren, auch aus dem Root-App-Verzeichnis:

tsc --p tsconfig.client.json


Um sowohl die Client- als auch die Serverkompilierung auszuführen, habe ich in package.json einen Befehl hinzugefügt:

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

Um dann sowohl Server als auch Client zu kompilieren, führe ich dies einfach aus meinem Root-App-Verzeichnis aus:

npm run tsc

Hoffe dieser Kommentar könnte dir helfen :-)

Alle 37 Kommentare

Hey @lazutkin. Derzeit wird dies nicht unterstützt, obwohl ich dieses Problem nur mit # 2869 verknüpfen möchte, da es etwas verwandt ist.

Der Compiler wählt die Datei tsconfig.json aus, die dem zu erstellenden Ordner am nächsten liegt, wenn Sie tsc ohne Argumente in einem Ordner ausführen. Wenn Sie also ein inneres Verzeichnis mit einer tsconfig.json haben, wird es vor dem im äußeren Verzeichnis abgeholt.

Ich denke nicht, dass wir die Integration / Überschreiben der Konfiguration von mehreren tsconfig.json unterstützen werden.

Für große Unternehmensanwendungen sind mehrere tsconfig-Dateien unverzichtbar.
Vorschlag: Jedes Mal, wenn tsc eine neue tsconfig-Datei in einem Unterverzeichnis findet, stoppt tsc hier und erstellt einen neuen tsc-Prozess mit einer eigenen tsconfig-Datei.

@Eisenspalter das klingt nach einem Build-Treiber-Job wie Grunzen, Schlucken oder Msbuild.

@mhegazy Ich stimme @Eisenspalter zu, da wir beide nicht über den Bauprozess sprechen, sondern über den Entwicklungsprozess, einschließlich des Schreibens von Quellen, Tests und anderer Aktivitäten, die wir vor dem Erstellen typescript einschließlich Intellisense, Typchecking usw. Darüber hinaus möchten wir, wie ich bereits sagte, für verschiedene Teile des Projekts verschiedene Techniken zur Organisation von Quellen anwenden (extern-interne Module, einzeln) Ausgabedatei usw.) und hier müssen einige Optionen durch separate tsconfig überschrieben werden.

@mhegazy Warum geschlossen? Bitte wieder öffnen.

Sie können heute mehrere tsconfig haben, die jeweils auf überlappende Dateigruppen verweisen. Eine in srctsconfig.json, eine in teststsconfig.json usw. Der Compiler / die Tools suchen die Datei, indem sie im Verzeichnisbaum nach der nächstgelegenen suchen. Sie können also eine dritte Datei im Stammverzeichnis haben, um alle abzufangen.

Dies alles funktioniert heute im Compiler und in den verschiedenen IDEs. Das ursprüngliche Problem bestand darin, eine Datei von einer anderen erben zu lassen. Ich glaube nicht, dass es dort genug Wert gibt, was die Komplexität rechtfertigt.

Für die zweite Ausgabe:

Jedes Mal, wenn tsc eine neue tsconfig-Datei in einem Unterverzeichnis findet, stoppt tsc hier und erstellt einen neuen tsc-Prozess mit einer eigenen tsconfig-Datei.

Wie bereits erwähnt, stellt eine tsconfig.json einen einzelnen Aufruf von tsc.js / tsc.exe dar. Wenn Sie mehrere Aufrufe ausführen möchten, sollten Sie einen Build-Treiber verwenden.

@lazutkin und @Eisenspalter beantworten damit die Fragen

@mhegazy
Es konnten nicht mehrere tsconfig.json zum Laufen gebracht werden. Zumindest mit TypeScript 1.7.3 wird nur eine tsconfig.json gelesen, die sich voraussichtlich im Stammverzeichnis (oder übergeordneten Verzeichnis) des Projekts befindet.

@Ziink Mein Kommentar oben war nicht über mehrere tsconfigs im selben Projekt. Es ging um mehrere Projekte / Verzeichnisse mit jeweils unterschiedlichen tsconfig. So ist das ts-Projekt aufgebaut, siehe https://github.com/Microsoft/TypeScript/tree/master/src . Jeder Ordner unter src hat eine andere tsconfig.json

Ich habe ein Projekt, das in TypeScript geschrieben ist, und ich möchte auf beide abzielen:

  1. Browser (sagen wir Dateien in /browser ) mit ES5 / AMD und
  2. nodejs (Dateien in server ) mit CommonJS und Generatoren (und async / await in TS).

Es gibt einige freigegebene Dateien, sagen wir im Ordner ( /common ), und es gibt Importe von common zu browser und server .
Wie kann ich eine solche Konfiguration erreichen, bei der die IDE-Unterstützung, alle Fehler usw. erhalten bleiben? Ich bin mir nicht sicher, ob die Diskussion meine Zweifel beantwortet hat.

@bartq Mit TS 1.8 würde ich zwei tsconfig-Dateien erstellen, eine für den Browser und eine für den Server, und /// Verweise in Ihren Dateien in beiden Unterprojekten zu den allgemeinen hinzufügen. Probieren Sie es aus und lassen Sie uns wissen, ob dies das Szenario betrifft oder ob noch Teile fehlen.

Eigentlich verwende ich diese beiden tsconfig.json -Dateien, WebStorm erkennt sie und führt die Kompilierung automatisch aus. Um genau zu sein, importiert Backend-Code eine Klasse aus dem Frontend-Code (stattdessen wird das Konzept common ), aber alles funktioniert einwandfrei.

Ich bekomme endlich die Lösung.

meine Bewerbungsstruktur:
- App /- app / client / (mein clientseitiger Quellcode)- app / server / (mein serverseitiger Quellcode)- app / build / (wo ich das js generiere)- App / Knotenmodule /- app / package.json- app / tsconfig.server.json- app / tsconfig.client.json

Inhalt von tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"ausschließen": ["node_modules", "client"]}

Inhalt von tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"ausschließen": ["Knotenmodule", "Server"]}


Wenn ich dann Server-Quellcode kompilieren möchte, verwende ich diesen Befehl aus dem App-Stammverzeichnis:

tsc --p tsconfig.server.json


Und um Client-Quellcode zu kompilieren, auch aus dem Root-App-Verzeichnis:

tsc --p tsconfig.client.json


Um sowohl die Client- als auch die Serverkompilierung auszuführen, habe ich in package.json einen Befehl hinzugefügt:

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

Um dann sowohl Server als auch Client zu kompilieren, führe ich dies einfach aus meinem Root-App-Verzeichnis aus:

npm run tsc

Hoffe dieser Kommentar könnte dir helfen :-)

Ich verstehe nicht, wo das Problem liegt. Warum können wir keine Konfigurationen mit unterschiedlichen Dateinamen unterstützen? Es ist mühsam, Unterordner NUR zu erstellen, um eine andere tsconfig-Datei zu haben.

Sie können. --p Argument kann ein Dateiname sein.

Die verschiedenen Dateinamen funktionieren jedoch nicht mit der Visual Studio Typoskript-Compiler-Erweiterung (ohne über CLI zu sprechen). Die einzige Möglichkeit, dies zu tun, besteht darin, jede tsconfig.json in ein Dummy-Verzeichnis zu stellen und sie mit der Option files mit den gewünschten Typoskripten verknüpfen zu lassen.

zum Beispiel

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

target / search / tsconfig.json würde

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

Und die anderen wären ähnlich.

Dies würde 3 Javascript-Dateien erzeugen, von denen jede ihre eigene Konfiguration von Dateien hat, die in einer gebündelt sind.

Natürlich können Sie eine andere Lösung zum Bündeln / Minimieren / Packen verwenden als den Typescript-Compiler.

Es ist nur so, dass der Typescript-Compiler bei der Optimierung wirklich gute Arbeit leistet - das ist einer der größten Vorteile bei der Verwendung von Typescript.

Es wäre also schön, wenn eine einzelne tsconfig.json mehrere Konfigurationen unterstützen könnte, indem sie einfach in ein Array von tsconfigs geändert wird:

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

So hört es sich an, wird in den späteren Kommentaren dieser Ausgabe angefordert, obwohl ich zustimme, dass es in der ursprünglichen Ausgabe mehr um Vererbung und das Überschreiben von Konfigurationen ging.

@mhegazy @bartq Ich kann es nicht mit dem Befehl tsc Laufen bringen .
Ich habe eine folgende Verzeichnisstruktur

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

Wenn ich jedoch tsc ausführe, wird nur die Konfiguration von app/tsconfig.json verwendet, der Rest wird ignoriert. Ich versuche, es in VSCode zum Laufen zu bringen: /

@tomitrescak Ich verwende WebStorm und es ist intelligent genug, um die nächstgelegene tsconfig.json zu finden und sie beim Bearbeiten einer Datei zu verwenden. Wahrscheinlich gibt es kein cmd-Tool, das das Ansehen mehrerer tsconfig.json unterstützt. Sie können es beispielsweise mit FB Watchman ausrollen.

Ja, ich würde gerne so etwas in VS Code haben. Ich führe die Kompilierung im Terminal aus. Funktioniert auch. VS Code identifiziert Fehler trotzdem korrekt.

Mehrere Konfigurationen wären großartig. Ich arbeite an einem React-Native-Projekt und habe im Grunde zwei Builds, die ich machen möchte:

  1. die Skripte meines React-Native-Projekts
  2. die im HTML verwendeten Skripte für die React-Native WebViews (Diagramme).

Die Konfigurationsvererbung wurde in TS 2.1 hinzugefügt und sollte heute in typescript@next verfügbar sein. Weitere Informationen finden Sie unter https://github.com/Microsoft/TypeScript/issues/9876 . Damit können Sie eine "master" tsconfig.json haben und diejenigen überschreiben, die Konfigurationen davon erben. Sie müssen noch mehrere tsconfig.json-Dateien erstellen, aber Ihre IDE sollte diese abholen.

Ich habe eine folgende Verzeichnisstruktur:

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

Root tsconfig.json haben:

{
  "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 haben den gleichen Wert außer:

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

Wenn ich es tue:

cd examples
tsc

Es kompiliert:

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

( dist false beinhaltet den externen Ordner src und wird wie aus dem Stammordner kompiliert)

Nicht helfen (in examples/tsconfig.json ):

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

Was mache ich falsch?

Ich habe ein Problem gefunden. Wenn in meinem examples/hello-world/any-file*.ts dieser Import:

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

Es ist das oben beschriebene Problem. Der folgende Import funktioniert wie erwartet:

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

Aber warum funktioniert die Direktive include Typoskript nicht wie erwartet?

Ich kann es nicht zum Laufen bringen
Es besteht auf " Warnung: Übergeordnetes Element tsconfig.json

@zhukovka Bitte protokollieren Sie ein neues Problem mit einem eigenständigen Repro, den wir lokal ausführen können

@ RyanCavanaugh Oh. Danke, ich habe es herausgefunden
Das Problem wird nur reproduziert, wenn eine Datei aus einem Testordner (ohne tsconfig.json) und die zweite Datei in einem 'src'-Ordner (mit tsconfig.json) geöffnet ist.
und die Datei aus dem Testordner importiert die aus dem src-Ordner. In diesem Fall wird in der Datei aus dem Ordner src die übergeordnete Datei tsconfig.json nicht angezeigt.

@RyanCavanaugh , die Unterstützung für das Kompilieren mit mehreren verschiedenen tsconfig.json scheint weiterhin etwas zu sein, das Entwickler gerne hätten. In meinen Fällen geht es im Allgemeinen darum, zu ändern, wohin die generierten Ausgabedateien gehen. Es scheint, als ob die Codegenerierungen durch so etwas wie das vorhandene paths Mapping gesteuert werden könnten, wodurch ich meinen generierten Code anders als die Quellen gestalten kann, würde möglicherweise der Bedarf an mehreren Projekten verringert.

Mein Anwendungsfall ist, dass ich eine große Legacy-Codebasis habe, die den strengeren Regeln für die Typprüfung nicht standhalten kann, und ich möchte sie in einer neuen Codebasis verwenden, in der strenge Prüfungen aktiviert sind, und ich kann den Legacy-Code nicht zu einer kompilieren Bibliothek, weil es eine Million Fälle gibt, in denen nicht alle Typen importiert werden, die zur Benennung der Typen für ihre Exporte erforderlich sind (# 9944). Ich möchte also nur die Legacy-Codebasis zur neuen Codebasis hinzufügen, aber nach laxeren Regeln kompiliert. Dies können nicht zwei verschiedene Kompilierungsschritte sein. Nur wenn der Compiler an Quelldateien in einem bestimmten Verzeichnis arbeitet, sollte er die laxer-Regeln verwenden.

Für mich besteht der Anwendungsfall darin, dass ein Teil des Repos mit Node ausgeführt wird und bis zu CommonJS-Modulen kompiliert werden muss, während der andere Teil zu ES6-Modulen kompiliert werden muss, um das Treeshaking in ES6 zu ermöglichen. Die Erfahrung ist nicht großartig, in meinem Fall wird viel mit TS_NODE_PROJECT Umgebungsvariablen herumgehackt. Es scheint definitiv etwas zu sein, das die nächste Person, die es wartet, zum Teufel verwirren könnte, wenn ich irgendwann Projekte ändere.

Ich würde immer noch gerne sehen, wie dies gelöst wird. Es wäre ein großer Gewinn für größere Projekte, die unterschiedliche tsconfig.json -Dateien pro Modul innerhalb eines Projekts erfordern.

@Robinfr Was löst die Funktion extends für Sie nicht?

Es tat es. Das habe ich nach diesem Beitrag herausgefunden. Eine Sache zu beachten ist jedoch, dass es nicht funktioniert hat, ohne die include auf die Dateien zu setzen, die k normalerweise nicht müssen, da es durch das Webpack geht.

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

@Robinfr https://github.com/robinfr was hat sich die Funktion https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends nicht für Sie lösen?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706 , oder schalten Sie den Faden https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yawlC1oTIks5siiZFgaJpZM4FMc8w .

Die Erweiterung von TS_NODE_PROJECT . Die andere Möglichkeit besteht darin, ein Projekt mit zwei tsconfigs in zu öffnen VS.code. Es gibt keine Möglichkeit (die ich kenne), VS mitzuteilen, welche Projektdatei verwendet werden soll, und das bedeutet, dass bei einigen Dateien Fehler aufgrund unterschiedlicher Einstellungen für diese Dateien in der entsprechenden tsconfig (z. B. etwas) nicht korrekt unterstrichen werden wie tsconfig.build.json).

@voy darf ich fragen, warum du eine andere tsconfig zum bauen hast? Soweit ich verstanden habe, verwendet VSCode die nächstgelegene tsconfig-Datei ( tsconfig.json ) zu der Datei, die Sie bearbeiten. Das einzige Problem, das ich bisher hatte, ist, dass Sie eine tsconfig-Datei im Stammverzeichnis haben müssen, bevor VSCode die Konfigurationen überhaupt zu verwenden scheint ...

@Robinfr sicher. Im selben Repository habe ich Dateien, die mit Webpack & Babel verarbeitet werden und ES6-Module verwenden, um das Baumschütteln zu ermöglichen. Andere Dateien sind Teil des Erstellungsprozesses und werden mithilfe des Knotens ausgeführt. Aus diesem Grund müssen Importe transpiliert werden. Ich bin mir nicht sicher, wie ich das umgehen könnte.

@voy hätten Sie diese Dateien nicht einfach in einem separaten Ordner? ZB 1 Ordner für alle Babel- und Webpack-Dateien und 1 für die Knotendateien. Dann können Sie einfach eine tsconfig.json für jeden dieser Ordner haben. Würde das nicht für dich funktionieren?

@Robinfr das wäre ideal, aber ich denke es ist nicht immer möglich in der realen Welt. Zum Beispiel möchten wir, dass alle unsere Konfigurationsdateien auch Typoskript sind, kompiliert und nach den gleichen Regeln wie die gesamte TypeScript-Codebasis gefusselt werden und einige Dateien sich im Stammverzeichnis des Projekts befinden müssen. Sie könnten symlink, aber das bringt manchmal andere Probleme hervor. Deshalb halte ich etwas Flexibleres für einen Vorteil.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

weswigham picture weswigham  ·  3Kommentare

MartynasZilinskas picture MartynasZilinskas  ·  3Kommentare

DanielRosenwasser picture DanielRosenwasser  ·  3Kommentare

jbondc picture jbondc  ·  3Kommentare

Roam-Cooper picture Roam-Cooper  ·  3Kommentare