Typescript: tsc sollte sich nicht darum kümmern und mit ts-Dateien außerhalb von rootDir fehlschlagen

Um herumzukommen, füge ich "ausschließen" zurück zu meinem tsconfig.json

Das rootDir wird verwendet, um die Ausgabeordnerstruktur zu erstellen. alle Dateien müssen sich unter rootDir befinden, damit der Compiler weiß, wohin die Ausgabe geschrieben werden soll. Ohne diese Einschränkung hat der Compiler zwei Optionen, wenn es Dateien gibt, die sich nicht unter rootDir befinden: 1. entweder werden sie an einer völlig unerwarteten Stelle ausgegeben oder 2. überhaupt nicht. Ich würde sagen, eine Fehlermeldung ist viel besser als ein stiller Fehler.

@mhegazy Danke für die Klarstellung. Mit dem Namen rootDir ich es als Root-Verzeichnis des Quellcodes genommen, ähnlich wie baseURL für den Browser. Wusste nicht, dass es nur für die Ausgabeordnerstruktur gilt.

Hier ist meine tsconfig.json:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": true,
        "noImplicitAny": true,
        "rootDir": "src",
        "outDir": "build"
    },
    "exclude": [
        ".idea",
        "build",
        "node_modules",
        "typings/globals",
        "typings/modules"
    ]
}

Meine Ordnerstruktur sieht so aus:

• Projekt
  
  
  
  • bauen
  
  
  • node_modules (symlink zu ../node_modules)
  
  
  • node_modules
  
  
  • src
  
  

Ich möchte, dass meine .ts-Dateien im src-Ordner kompiliert und mit denselben Ordnerstrukturen in den Build-Ordner ausgegeben werden. Ich tue dies, damit ich mein Dokumentenstammverzeichnis auf den Build-Ordner setzen und meine src aus dem Doc-Stammverzeichnis heraushalten kann. Ich erhalte Fehlermeldungen zu .ts-Dateien im Ordner node_modules, dieselben Fehlermeldungen wie bei OP. Beachten Sie oben, ich habe node_modules ausgeschlossen. Warum beschwert sich tsc darüber?

@HillTravis Ihr Problem scheint das gleiche zu sein wie https://github.com/Microsoft/TypeScript/issues/9552.

@mhegazy Ich bin mir nicht sicher, ob es dasselbe ist. Ja, meine Struktur enthält einen Symlink, aber überall, wo dieser Symlink existiert, sollte ignoriert werden.

In #9552 gibt es keinen src-Ordner, was bedeutet, dass der Ordner node_modules im erstellten Pfad vorhanden ist. In meinem Szenario ist das Stammverzeichnis, das tsc untersuchen sollte, src, das keine node_modules enthält. Es sollte also nicht auf diesen Ordner schauen. Darüber hinaus habe ich den Ordner node_modules über meine tsconfig.json explizit ausgeschlossen. Es sollte also doppelt ignoriert werden. Ich habe auch den Ordner build ausgeschlossen, und das sollte den Symlink zu node_modules darin abdecken.

Auch in #9552 wurden die Fehlermeldungen oder die fehlgeschlagene Kompilierung nicht erwähnt.

Ich sollte auch erwähnen, dass ich TypeScript 1.8.10 verwende.

Konkret lauten die Fehlermeldungen:

Fehler TS6059: Datei '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.module.ts' ist nicht unter 'rootDir' '/Users/thill/Projects/ nrc/client/src'. 'rootDir' soll alle Quelldateien enthalten.

Fehler TS6059: Datei '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.ts' ist nicht unter 'rootDir' '/Users/thill/Projects/nrc/ client/src'. 'rootDir' soll alle Quelldateien enthalten.

Fehler TS6059: Datei '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/timepicker-event-interface.ts' ist nicht unter 'rootDir' '/Users/thill/Projects/ nrc/client/src'. 'rootDir' soll alle Quelldateien enthalten.

@HillTravis Sie können mir diesbezüglich vertrauen :) Es ist unsere inkonsistente Behandlung von Symlinks, die den Compiler aus der

Als Test habe ich versucht, den Symlink zu entfernen. Eigentlich habe ich den gesamten build Ordner gelöscht. Dann habe ich tsc erneut ausgeführt und den Fehler immer noch gesehen.

Während weiterer Tests habe ich versucht, den In-Code-Import und die Verwendung dieses bestimmten Knotenmoduls (ng2-datetime) auszukommentieren, und der Fehler ging weg. Nur wenn ich versuche, dieses Knotenmodul zu importieren, wird der Fehler unabhängig vom Symlink angezeigt.

Wenn Sie sich die Quelle für dieses Paket auf GitHub ansehen, sehen Sie, dass die Datei package.json den Parameter "main" auf "ng2-datetime.js" gesetzt hat, obwohl der Autor auch die .ts-Datei mit derselben veröffentlicht hat Name. Dies scheint das Problem zu verursachen. Wenn ich .d.ts-Dateien erstelle und die .ts-Dateien lösche, verschwindet das Problem. Es wurde ohne Probleme kompiliert, selbst nachdem der Symlink wieder hinzugefügt wurde.

Bei allem Respekt sehe ich nicht, wie dieses Problem speziell mit dem Symlink zusammenhängen könnte. Es scheint nur im Allgemeinen Probleme zu verursachen, wenn der Autor die .ts-Dateien in das Paket einfügt.

Wisst ihr ob es dafür einen Workaround gibt? Das obige OP sagte, dass dies umgangen wurde, indem "exclude" wieder zur tsconfig.json hinzugefügt wurde. Ich habe das Verzeichnis bereits ausgeschlossen, aber es wird immer noch versucht, es zu kompilieren.

Wisst ihr ob es dafür einen Workaround gibt? Das obige OP sagte, dass dies umgangen wurde, indem "exclude" wieder zur tsconfig.json hinzugefügt wurde. Ich habe das Verzeichnis bereits ausgeschlossen, aber es wird immer noch versucht, es zu kompilieren.

Dies mag mit einem anderen zusammenhängen, aber ich kann es gerade nicht finden. Beim Auflösen nach einem Typ versucht tsc immer, ihn von node_modules , während er nicht vorhanden ist (bezogen auf typings ).

"tsc sollte sich nicht darum kümmern und mit ts-Dateien außerhalb von rootDir fehlschlagen" Ich stimme zu.

Ich kann nicht verstehen, warum Typescript JS-Dateien außerhalb des RootDirs durchsucht, da dort der gesamte Quellcode sein sollte.
Die Fehlermeldung sagt "'rootDir' soll alle Quelldateien enthalten", dann sollte nichts außerhalb dieses Verzeichnisses erwartet oder als Quelldatei angenommen werden, soweit es TS betrifft!

Wenn dies "Working as Intended" ist, was genau ist dann die Absicht oder Motivation dieses Verhaltens? Gibt es einen Fall, in dem TS Quelldateien kompilieren möchte, die sich außerhalb des rootDir befinden?

Andererseits löst das Hinzufügen eines "include"-Abschnitts in tsconfig das Problem. Wenn TS mit einzuschließenden Dateien oder Verzeichnissen ausgestattet ist, sucht TS keine anderen Dateien außerhalb dieser.

mit Typoskript 1.8.10

Ich hatte einen node_modules Ordner in meinem Homedir ~/node_modules . Das Ausführen von tsc aus meinem Projektverzeichnis ~/projects/myProject/ dass sich Typescript über die folgenden Dateien beschwerte

../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/config.d.ts(29,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(36,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(68,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(75,111): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/request.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/services/glacier.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.

sehr verwirrend - obwohl ich nicht sicher bin, warum ich zunächst einen Knotenmodule-Ordner in meinem Home-Verzeichnis hatte.

@iwllyu können Sie Ihr Projekt auf [email protected] überprüfen und ein neues Problem melden, wenn Sie immer noch Probleme haben.

Habe immer noch das Problem mit 2.1.4, obwohl es sich über einen anderen Satz von Dateien beschwert

Using tsc v1.8.10
../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(27,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(34,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(66,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(73,111): error TS1110: Type expected.

Using tsc v2.1.4
../../node_modules/aws-sdk/lib/config.d.ts(38,37): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/request.d.ts(164,16): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/s3/managed_upload.d.ts(15,16): error TS2304: Cannot find name 'Promise'.

Ich werde ein Projekt erstellen, um den Testfall zu isolieren

Nun, ich habe es mit einem neuen Projekt versucht und es ist nicht passiert. Da dies ein älteres Projekt ist und ich es bereits durch Entfernen des zusätzlichen Ordners node_modules behoben habe, werde ich keine Zeit mehr damit verbringen, es neu zu erstellen. Danke für die Hilfe!

Über diesen Fall. Wenn alles, was Sie importieren, Typen sind (wie ich wirklich auf diesem "Front-Typescript, Back-Typescript"-Wave-Ding surfe) von außen - kann tsc vielleicht unterscheiden, was ich tue?
Ich teile nur Typen meiner Entitäten vom Backend bis zu meiner Frontend-Anwendung. Ausgabe natürlich ohne Typen und Importe dieser Klassen (da sie nur für Kompilierzeit und Intellisense verwendet werden).

Hatte das auch.
Typoskript ist für unser Team zu einschränkend - wenn man den Flow jetzt bedenkt.

Leute, gibt es dazu jetzt eine Lösung? Verwenden von Typen aus Clientcode im Back-End-Code und anderweitig.

was ist die beste möglichkeit? hier und da kopieren und einfügen und ändern, wenn ich Typen ändere?

Ein Root-Verzeichnis für 2 Projekte zu erstellen ist keine Option, da das Backend tsconfig.json Informationen über jsx hat und in commonjs kompiliert, wenn ich es2015 verwenden kann?

Funktioniert baseUrl für Sie?

@unional ändert baseUrl nicht und bricht alle node_modules-Importe - es muss nicht geschrieben werden

import * as request from "superagent";

aber

import * as request from "node_modules/superagent/..something";

?

Bleh, das funktioniert wirklich wie beabsichtigt? Ich bin gerade darauf gestoßen, ich habe Typoskript gesagt, dass sich meine Quelle alle in einem bestimmten Ordner befindet (über rootDir ) und dann hat es _komplett ignoriert, was ich gesagt habe_, weil ich zufällig eine einzelne Datei mit einem .ts Erweiterung

Das fühlt sich wirklich wie ein Fehler an, wenn ich dem Compiler über rootDir mitteile, wo sich meine Quelle befindet, sollte er diese Einstellung nicht vollständig ignorieren und meine Ausgabeordnerstruktur ändern, weil er denkt, dass ich vielleicht etwas falsch gemacht habe. Es sollte einfach alle Dateien ignorieren, die sich nicht in rootDir . Alternativ sollte es schwer fehlschlagen, keine Ausgabe mehr auszugeben, die überhaupt nicht mit meiner gewünschten Ausgabeordnerstruktur übereinstimmt!

Für jeden, der nach mir kommt, wird Folgendes tun, was Sie _eigentlich_ wollen:

{
    "compilerOptions": {
        "outDir": "./output",
        "rootDir": "./source",
    },
    "include": [
        "source"
    ]
}

Ich habe Typoskript gesagt, dass sich meine Quelle in einem bestimmten Ordner befindet (über rootDir)

Das ist nicht das, was rootDir bedeutet! rootDir bedeutet "Diesen Ordner als relative Basis für die Berechnung der Pfade in outDir ". Welche Dateien zu Ihrer Zusammenstellung gehören, ist eine separate Frage, die mit files und/oder include / exclude beantwortet wird

Auch wenn ich das akzeptiere, ist das aktuelle Verhalten IMO immer noch ein Fehler. Wenn ich irgendwelche TS-Dateien außerhalb des angegebenen Verzeichnisses habe, dann ist rootDir _nicht_ die Grundlage für die Berechnung der Pfade in outDir , was bedeutet, dass die von mir angegebene Konfiguration vollständig ignoriert wird.

Ich denke, ein hartes Versagen wäre viel besser, da der Compiler effektiv denkt, dass ich eine ungültige Konfiguration angegeben habe. Das Ignorieren einer ungültigen Konfiguration ist (IMO) nicht der richtige Weg, um mit dieser Fehlerklasse umzugehen.

Beispiel-Fehlermeldung, die viel klarer wäre (zusammen mit einem harten Ausfall):

TSC hat Typescript-Dateien außerhalb von rootDir gefunden und kann daher nicht mit der Kompilierung fortfahren. Ändern Sie entweder rootDir , um alle Typoskriptdateien einzuschließen, oder schließen Sie Dateien außerhalb von rootDir aus oder schließen Sie nur Dateien innerhalb von rootDir ein.

Hinweis: Ein großer Teil des Grundes, warum sich das aktuelle Verhalten von rootDir sehr falsch anfühlt, liegt genau darin, dass es keinen Sinn macht, Dateien außerhalb von rootDir zu haben. Wenn man sich (oder den Compiler) fragt, was es bedeutet, Dateien außerhalb von rootDir zu kompilieren, ist die einzige Antwort "es macht keinen Sinn". Daher kommt man zu dem natürlichen Schluss, dass rootDir auch sourceDir angibt.

Das Böse liegt in der Namensgebung. Es bedeutet wirklich relativePathBaseDir oder so ähnlich.

Mir ist auch aufgefallen, dass include normalerweise "auch hier schauen" bedeutet, aber in diesem Fall "nur hier schauen".
Ich wäre vernünftig, wenn es einen anderen Namen hätte und obligatorisch wäre.

IMO sollte dieser Kommentar besonders berücksichtigt werden, um zu bestätigen, dass dies tatsächlich ein Fehler ist und als solcher erneut geöffnet werden sollte:

Hinweis: Ein großer Teil des Grundes, warum sich das aktuelle Verhalten von rootDir sehr falsch anfühlt, liegt genau darin, dass es keinen Sinn macht, Dateien außerhalb von rootDir zu haben. Wenn man sich (oder den Compiler) fragt, was es bedeutet, Dateien außerhalb von rootDir zu kompilieren, ist die einzige Antwort "es macht keinen Sinn".

Tatsächlich macht es keinen Sinn . " Quelldateien außerhalb von rootDir " sind einfach keine Quelldateien , unabhängig von ihrer Dateierweiterung oder ihrem Inhalt. Der Compiler wird sie niemals kompilieren. Warum beschwert er sich dann über ihre Existenz? Ist er eifersüchtig, dass es Akten gibt, die nicht unter seine Herrschaft fallen?

+100, dass dies ein Fehler ist (eigentlich ein böser). Betrachten Sie folgende Verzeichnisstruktur:

- src/
  - module.ts
- test/
  - module.test.ts
- out/
  - module.js

Ich möchte, dass tsc nur src kompiliert, da ich Tests mit ts-node ausführe. Wenn rootDir: 'src' wird, wird derzeit ein Kompilierungsfehler verursacht. Wenn Sie Tests und andere Dinge, die Sie nur ausführen möchten, mit ts-node (oder vielleicht sogar separat kompilieren?) als "ausgeschlossen" markieren , passieren schlimme Dinge (z.

Tatsächlich erfüllt keine Kombination aus rootDir , excluded und allen anderen Optionen alle Anforderungen (Tests von der Kompilierung ausschließen, während man sie trotzdem ausführen und mit ihnen arbeiten kann).

Und ich glaube nicht wirklich, dass mein Anwendungsfall einzigartig ist, daher lohnt es sich, zumindest aus UX-Sicht das Etikett "Arbeit wie beabsichtigt" zu überdenken.

Die Einrichtung von src / test / out war ein Schlüsselszenario, das von Projektreferenzen angesprochen wurde

Ich habe dieses Problem gefunden, weil ich gegoogelt habe, warum Typescript versucht hat, meine Datei webpack.config.js zu kompilieren, nachdem ich rootDir .

Ich habe Typoskript gesagt, dass sich meine Quelle in einem bestimmten Ordner befindet (über rootDir)

Das ist nicht das, was rootDir bedeutet! rootDir bedeutet "Diesen Ordner als relative Basis für die Berechnung der Pfade in outDir verwenden". Welche Dateien zu Ihrer Zusammenstellung gehören, ist eine separate Frage, die mit Dateien und/oder Einschluss/Ausschluss beantwortet wird

Das ist die Antwort! Die Dokumente für rootDir sagen

Gibt das Stammverzeichnis der Eingabedateien an

Was ich als "input_source_ files" verstanden habe. Ich empfehle, dass der Kommentar von @RyanCavanaugh die aktuelle Erklärung für diese Option ersetzt.

Hier zu verlinken - https://github.com/Microsoft/TypeScript/issues/11299 ist ein Duplikat dieses Problems. (Lösung: Verwenden Sie include/exclude, um die zu kompilierenden Dateien anzugeben, rootDir gibt NICHT an, welche Dateien kompiliert werden sollen.)

@mhegazy Würden Sie diesen Thread zu diesem Zweck kommentieren? Darauf scheint sich der Fragesteller zu beziehen (verwirrt darüber, warum TS Dateien außerhalb von RootDir ansieht, dasselbe Missverständnis, was rootDir bedeutet).

Ich stehe auch vor diesem Problem und konnte es nicht lösen.

Die tsc-Kompilierung führt den Baum aus meinem enthaltenen Verzeichnis in die übergeordneten Ordner und verursacht doppelte Typfehler.

Ich habe eine verschachtelte Ordnerstruktur, die so aussieht:

└─src
└─package.json
└─node_modules
└─tsconfig.json
└─example
│ └─src
│ └─package.json
│ └─node_modules
│ └─tsconfig.json

Wenn ich nun versuche, tsc aus dem Beispielverzeichnis heraus auszuführen, erhalte ich die folgende Fehlermeldung:

node_modules/@types/react/index.d.ts:2809:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2809         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2814:14
    2814         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

Wie Sie am Fehler sehen können, wandert tsc den Baum nach oben und aus dem Beispielordner heraus und sucht im Ordner node_modules des übergeordneten Verzeichnisses! Was sich noch schlimmer anfühlt, ist, dass ich versucht habe, das übergeordnete Verzeichnis node_modules mit geringer Wirkung explizit zu ignorieren.

Hier ist die tsconfig des Beispielverzeichnisses:

{
  "compilerOptions": {
    "target": "es5",
    "experimentalDecorators": true,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "jsx": "react"
  }
,
  "typeRoots": [
    "./node_modules/@types"
  ],
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "../node_modules"
  ]
}

Wie kann ich dieses Problem lösen? Keines der oben genannten scheint bei mir zu funktionieren

@lexwebb Ich hatte das gleiche Problem. Überprüfen Sie in Ihren yarn.lock Dateien, dass @types/react die gleichen Versionen haben.
Siehe https://stackoverflow.com/questions/52399839/typescript-duplicate-identifier-librarymanagedattributes.

Ich bin hier gelandet, weil mein Assets-Ordner eine "MPEG Transport Stream"-Videodatei mit der Erweiterung .ts sodass tsc abstürzte, auch wenn der Ordner nicht in meinem rootDir Pfad war

Ich habe es behoben, indem ich den Assets-Ordner in die exclude Pfade hinzugefügt habe, aber es war ein störendes Verhalten 🤔

Es stellte sich also heraus, dass ich sowohl im übergeordneten als auch im untergeordneten Paket json eine etwas andere Version von Reagieren hatte. Das genaue Abgleichen der Versionen hat das Problem behoben. Es ist immer noch ein Schmerz, dass Sie die Überprüfung des Formulartyps der übergeordneten Verzeichnisse nicht ausschließen können.

Ich vermute, das wird nie behoben. Bin gerade auf das gleiche Problem gestoßen. Wie das "wie beabsichtigt funktioniert" ist mir schleierhaft. Ich denke, die Absicht war, den Compiler auf eine unsinnige Weise auszuführen.

Aus meiner eigenen Erfahrung ist der Grund, warum ein Typoskript-Build aus Ihrem rootDir Baum herauswandert und versucht, Dinge zu erstellen, die Sie nicht erwarten, die Tatsache, dass Sie (absichtlich oder versehentlich) direkt oder indirekt auf etwas darin verwiesen haben Bereich aus Ihrem rootDir . Wenn Sie dies tun, folgt der Build dem Referenzbaum, unabhängig davon, ob Sie versucht haben, den Bereich auszuschließen, der die referenzierte Datei enthält. Manchmal kann es ein PITA sein, der versucht herauszufinden, wie / wo Sie es getan haben - aber ich finde immer, dass es meine eigene Schuld ist - nicht die Schuld von tsc . Es tut nur das, was ich ihm gesagt habe.

Wann immer mir das auffällt, liegt es an den Typen. Ich importiere eine Schnittstelle oder etwas, das in einer Datei lebt, die etwas anderes importiert, das in einer Datei lebt, die etwas anderes importiert ... bis ich schließlich etwas importiere, das in einer Datei außerhalb meiner rootDir lebt und sehr oft in etwas, das ich in meiner config explizit ausschließen möchte.

HTH einige von Ihnen gehen Ihrem Schmerz auf den Grund. Kein Konfigurationsaufwand wird Sie davon abbringen - Sie müssen nur Ihre Importstruktur streng kontrollieren.

@kpturner Das klingt super vernünftig, aber – ein Barebone-Testprojekt ohne

Wirklich? Das habe ich noch nie gesehen :)

Ausgeschlossene Ordner werden in allen meinen Projekten immer ausgeschlossen, außer wenn die Umstände vorliegen, auf die ich anspiele.

Gibt es in diesem Thread Beispiele für nackte Knochen? Von meinem Handy aus schwer zu sagen.

Entschuldigung, Ausschluss ist nicht Teil der „nackten“ Situation, auf die ich mich beziehe. Ich stelle nur fest, dass Importe keine Ursache für das Verhalten zu sein scheinen (obwohl es in diesem Fall sinnvoller wäre).

dh das Kompilieren von so etwas führt zu einem Fehler.

-src / src.ts <- no imports -test / test.ts -out -tsconfig.json {"rootDir": "src", "outDir": "out"}

Aber wenn Ihr tsconfig.json aussieht, würde ich erwarten, dass Typescript alles im Verzeichnis src und alles im Verzeichnis test kompiliert. Wenn Sie nur wollen , dass es nur sieben Sachen transpile src und Ausgabe an den out Verzeichnis dann tsconfig.json sein müsste

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    }
}

Dann würde es einen TS6059-Fehler auslösen, weil Sie einige Dateien außerhalb von rootDir . Diese müssen Sie dann ausschließen:

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    },
    "exclude": [
        "test"
    ]
}

die beim Transpilieren einen Ordner namens out mit einem Unterordner von src mit src.js . Der Ordner test wird komplett ignoriert. Das würde ich erwarten - nein?

Äh, mein Beispiel tsconfig hätte rootDir und outDir unter compilerOptions wie Sie in Ihrem ersten Beispiel zeigen. Sie haben auch Recht, dass, wenn Sie test , test und seine Dateien ausgeschlossen werden. Ursprünglich dachte ich, Sie würden sagen, dass ein (oder der) Schuldiger des TS6059-Fehlers eine Datei in rootDir , die etwas von außerhalb von rootDir importiert – obwohl ich glaube, dass ich Sie falsch verstanden habe. Unabhängig davon stimme ich anderen hier zu, dass ich überrascht bin, dass Verzeichnisse außerhalb von rootDir explizit ausgeschlossen werden müssen, wie Sie es beschreiben.

Nein, ich habe (zuvor) gesagt, dass der Referenzbaum dazu führen kann, dass Dinge in Ihrer Ausschlussliste transpiliert werden - etwas anders.

Der TS6059-Fehler ist anfangs ein wenig beunruhigend - aber ich sehe ihn als TS, der versucht, mir zu helfen, Fehler zu vermeiden. Wenn ich mir die Mühe gemacht habe, ein rootDir zu definieren und dann ein Plonk-Typoskript außerhalb dieses rootDir fliegt, dann sagt TS effektiv "oi - Sie haben ein Typoskript erstellt, zu dem ich nicht gelangen kann - ist das richtig?"

Ich antworte entweder „Nein, es ist nicht richtig, ich habe es vermasselt“ und verschiebe die Dateien in rootDir
ODER
Ich sage "Ja, es ist richtig und es tut mir leid, dass ich es Ihnen nicht mitgeteilt habe" - und füge es dann der Liste der ausgeschlossenen Dateien hinzu.

Das ist viel zu kompliziert. Ich habe ein Monorepo und kann anscheinend keine Möglichkeit finden, jedes Paket für sich selbst richtig zu kompilieren und die richtige Verzeichnisstruktur auszugeben, während lokale Pakete (aus demselben Monorepo) mit der Option paths importiert werden.

Entweder enthält die Verzeichnisstruktur im Ausgabeverzeichnis unerwünschte übergeordnete Ordner oder tsc beschwert sich über Dateien außerhalb des Stammverzeichnisses.

Kann nicht so kompliziert sein oder?

Egal welche Optionen in welcher Kombination ich verwende, tsc scheint kein Monorepo mit paths auf lokale Pakete im selben Monorepo verweist. Ich habe versucht --build , --project , references , paths , extends , rootDir , rootDirs , include , exclude , baseUrl , outDir in allen möglichen Kombinationen mit unterschiedlichen Werten und am Ende beschwert es sich, dass Dateien nicht innerhalb der rootDir oder es vermasselt es, indem es eine falsche Verzeichnisstruktur innerhalb von outDir .

Ich würde das, was ich habe, nicht als Monorepo bezeichnen, aber ich habe drei verschiedene Projekte im selben Repo - und ich kann jedes unabhängig ohne Probleme oder Störungen durch die anderen transpilieren. Jedes Projekt hat seine eigene tsconfig

Nach einiger Zeit des Probierens und Bastelns konnte ich ein Monorepo mit lerna und typescript zum Laufen bringen. Die Typoskript-Konfiguration verwendet references in Kombination mit paths und erstickt nicht mehr an der Verwendung von rootDir .

Das rootDir wird verwendet, um die Ausgabeordnerstruktur zu erstellen. alle Dateien müssen sich unter rootDir befinden, damit der Compiler weiß, wohin die Ausgabe geschrieben werden soll.

Was ist mit Dateien, die keine Ausgabe erfordern? Eine Json-Datei außerhalb von Root haben:

const errors = require("../../../../errors.json");

Da ich die ES6-Version nicht kompilieren kann:

import * as errors from "../../../../errors.json";

Mit der ersten Version verliere ich jedoch die Typsicherheit.

@mhegazy Dieses Problem wurde vor 3 Jahren geschlossen. Es scheint jedoch, dass es 3 Jahre später immer noch eine Quelle der Verwirrung ist.

Könnten Sie bitte diesen Status "Funktioniert wie beabsichtigt" erneut aufrufen? Angesichts der Reaktion der Community in diesem Thread kann man ziemlich sicher sagen, dass es sich nicht so verhält, wie die Community es erwartet . Egal, ob es sich um ein Dokumentationsproblem, das Umbenennen dieser Option, das Ändern ihres Verhaltens oder das Hinzufügen einer neuen Option handelt, ich glaube, es gibt tatsächlich ein Aktionselement auf Ihrer Seite, das festgelegt werden muss.

Ich kann verstehen, dass Sie viel höhere Prioritäten haben als diese, aber dieses Thema geschlossen zu halten, ohne Anzeichen dafür, dass das hier gegebene Feedback jemals wertgeschätzt wurde, vermittelt Typescript, um ehrlich zu sein, kein wirklich gutes Bild.

@ngryman Welchen nächsten Schritt haben wir? rootDir hat eine Definition - dies ist die gemeinsame Wurzel meiner Quelldateien. Wenn sich eine Datei nicht in diesem gemeinsamen Stammverzeichnis befindet, ist dies nach der Definition von rootDir ein Fehler. Diese Definition ist dokumentiert. Ich kann nichts daran ändern, dass die Leute ihre eigenen Definitionen für rootDir erfunden haben und dann überrascht sind.

Das ist, als würde man zu Starbucks gehen und sagen, dass die Bitte um einen Latte nicht dazu führen sollte, dass man eine Mischung aus Espresso und aufgeschäumter Milch bekommt. Es ist nicht umsetzbar, weil Sie mit einer Definition argumentieren . Wenn Sie ein anderes Getränk wünschen, bestellen Sie etwas anderes. Wenn Starbucks nicht die Art von Getränk anbietet, die Sie möchten, machen Sie einen Vorschlag, was dieses Getränk sein sollte und woraus es hergestellt werden sollte.

Wie ich in https://github.com/microsoft/TypeScript/issues/9858#issuecomment -370653478 erwähnt habe, denke ich, dass die Lösung für dieses Problem einfach eine bessere Fehlermeldung ist. Als ich darauf stieß und schließlich dieses GitHub-Problem fand, war meine größte Frustration, wie viel Zeit ich damit verschwendet habe, das Problem herauszufinden, und dann dachte, es sei ein Compiler-Fehler, und dann einen Repro-Fall erstellt und dann gefunden ein doppelter Fehler, der sagt, dass "wie beabsichtigt funktioniert". Ein schnelles Scheitern mit einer klaren Fehlermeldung hätte mir das alles erspart.

Wenn Quelldateien außerhalb von rootDir , bedeutet dies, dass das TypeScript-Projekt falsch konfiguriert ist. Dem Benutzer eine klare Nachricht zu geben, die dies zusammen mit einer Anleitung zur Behebung des Problems anzeigt, würde das Problem meiner Meinung nach für viele Leute lösen.

@RyanCavanaugh Danke für deine schnelle Antwort.

Wenn ich auf diese Seite gehe: https://www.typescriptlang.org/docs/handbook/compiler-options.html. Ich habe folgende Definition gelesen:

Gibt das Stammverzeichnis der Eingabedateien an. Wird nur verwendet, um die Ausgabeverzeichnisstruktur mit --outDir zu steuern.

Ich verstehe buchstäblich, dass es " nur verwendet wird, um die Ausgabeverzeichnisstruktur einzige Verwendung “. Wie konnte ich nur vermuten, dass dies nicht das einzige ist, was der Compiler in Wirklichkeit tut, sondern dass er auch Fehler ausgibt, wenn ich Typescript-Dateien außerhalb dieses Verzeichnisses habe.

Vielleicht übersehe ich etwas, aber wenn das der Fall ist, bin ich bei weitem nicht der einzige. Wenn Sie also ein Produkt haben und viele Ihrer Benutzer Ihr Produkt nicht verstehen, gibt es nur zwei Wege: Entweder Sie halten Ihre Benutzer für dumm oder Sie haben es versäumt, etwas klar zu kommunizieren. Ich hoffe du neigst nicht zum ersten

Um mit Ihrem Starbuck-Beispiel abzuschließen, schreiben Sie gut "Mischung aus Espresso & Dampfmilch" in die Zutatenliste, damit ich weiß, was ein Latte ist und ich nicht raten muss.

Die Implikation einer Datei außerhalb von rootDir wäre, dass TS eine Datei außerhalb von outDir ausgeben würde, was meiner Meinung nach ein offensichtlich schlechtes Verhalten ist.

Die Fehlermeldung könnte besser sein - ich würde mich über einen Vorschlag oder eine PR dafür freuen.

Die Dokumente könnten immer besser sein - ich würde mich auch dort über konkrete Ideen freuen, wie man die Dinge klarer kommunizieren kann.

Unterstellen, dass ich die Leute dumm nenne, möchte ich nicht mehr.

Die Implikation einer Datei außerhalb des rootDir wäre, dass TS eine Datei außerhalb des outDir ausgeben würde, was meiner Meinung nach ein offensichtlich schlechtes Verhalten ist.

Mir ist immer noch sehr unklar, warum der Compiler nicht einfach in rootDir "chrooten" würde und Dateien außerhalb dieses Verzeichnisses nicht berücksichtigt. Als Benutzer, dem wahrscheinlich der Kontext zu tsc Interna und -Historie fehlt, ist dies für mich definitiv kein vorhersehbares Verhalten.

Ein Beispiel, das ich aus meinem Kopf heraus geben kann, ist Jest, das die gleiche Option bietet: https://jestjs.io/docs/en/configuration#rootdir -string. AFAIK Jest berücksichtigt keine Testdateien außerhalb von rootDir . Ich würde hier zum Beispiel das gleiche Verhalten erwarten.

Die Dokumente könnten immer besser sein - ich würde mich auch dort über konkrete Ideen freuen, wie man die Dinge klarer kommunizieren kann.

Ich freue mich, dass Sie hier über Verbesserungen nachdenken. Der Vorschlag von @MicahZoltu könnte interessant sein.

Meinerseits kann ich wiederholen, dass ich nicht denke, dass rootDir vorhersehbar ist (daher die Reaktion der Leute), aber so wie ich es verstehe, ist eine Änderung des Verhaltens dieser Option nicht in Betracht zu ziehen. Als Kompromiss könnte ich auch vorschlagen, rootDir in einen aussagekräftigeren Namen umzubenennen, outBaseDir könnte ein Kandidat sein. Aber es gibt wahrscheinlich einen besseren Namen.

Unterstellen, dass ich die Leute dumm nenne, möchte ich nicht mehr.

Ich habe nichts unterstellt und es tut mir leid, wenn Sie das so aufgefasst haben. Ich habe nur eine ganz einfache Tatsache gesagt: Wenn sich Benutzer über etwas beschweren, das sie nicht verstehen, gibt es effektiv nur 2 Wege. Ich kam zu dem Schluss, dass ich hoffe, dass Sie sich nicht an den ersten lehnten. Dass Sie sich mit einem dieser Wege verbinden, ist ehrlich Ihnen überlassen.

Ich glaube, ich habe gesagt, was ich zu sagen hatte, insbesondere, wenn ich offenes Feedback darüber gegeben habe, wie dieser Thread behandelt wurde. Ich lasse also anderen Raum, um Lösungen vorzuschlagen.

@ngryman Ich stimme zu, dass die Definition von rootDir und was es tatsächlich tut, nicht zusammenzupassen scheint. Wenn Sie ein neues ts-Projekt erstellen (über tsc --init ) ist der Kommentar in tsconfig.json für rootDir ähnlich dem, den Sie in /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */ . Wenn ich ein Verzeichnis mit _input_-Dateien anliefere, erwarte ich, dass die einzigen Dateien, die es überhaupt zu kompilieren in Betracht zieht, sich nach der Definition von input in diesem Verzeichnis befinden.

@RyanCavanaugh Es mag vor 4 Jahren sinnvoll gewesen sein, einen nur verwendet wurde, um in Javascript kompiliert zu werden. Natürlich möchte ich keine fehlenden Dateien! Aber jetzt, mit der Popularität der Typoskriptausführung, wie ts-node , scheint es, als wäre tsc ein wenig neidisch auf mich.

Und die Vorstellung, dass Typoskriptdateien außerhalb von rootDir eine falsche Projektkonfiguration implizieren, ist einfach falsch. Ich brauche nicht, dass meine in Typoskript geschriebenen Unit-Tests in Javascript kompiliert werden. ts-node ist einfach schneller und ich kann alle Vorteile der Schreibmaschine beim Schreiben von Tests genießen.

Ich stimme @CodySchrank zu . Ich bin damit einverstanden, dass TS fehlschlägt, wenn eine Quelldatei innerhalb des rootDir eine Datei außerhalb davon referenziert / importiert - das ist zu erwarten.

Ich kann jedoch nicht verstehen, dass TypeScript selbst nicht verwandte Dateien außerhalb von rootDir durchsucht und Fehler ausgibt, während dies einfach Konfigurationsdateien für verschiedene Tools sind, wie Scherz oder was auch immer. Ich meine, was ist der Sinn? Diese sind nicht einmal Teile meiner Anwendung und werden nirgendwo direkt referenziert / importiert, und mein Gott, warum sollte ich überhaupt wollen, dass sie in den resultierenden Build gebündelt werden ...

Ich frage mich, welche Auswirkungen es hätte, diesen Fehler in eine Warnung umzuwandeln. Nachdem ich den Code kurz durchgeblättert habe, scheint es sicherlich möglich zu sein, aber ich bin definitiv kein Experte für den tsc-Build-Prozess. Es scheint ein glücklicher Mittelweg zu sein, uns über ein potenzielles Problem auf dem Laufenden zu halten, aber auch es zu umgehen, wenn wir wollen.

Die Einrichtung von src / test / out war ein Schlüsselszenario, das von Projektreferenzen angesprochen wurde

Dies erfordert mindestens eine separate Projektkonfiguration für jeden Root-Ordner (https://www.typescriptlang.org/docs/handbook/project-references.html). Nachdem ich die Anweisungen gelesen hatte, kam ich ohne ein gutes Verständnis für die Umsetzung des Musters weg und ich fühlte mich, als würde mir ein Presslufthammer ausgehändigt, als ich eine Fliegenklatsche verlangte.

Sicher, die Verwaltung von Zusatzmodulen als separate Unterprojekte in meinem Quellordner ist effizienter, aber ich kompiliere hier nicht Lodash. Was ich möchte, ist, viele Dateien, wie Test- und Benchmark-Dateien, in einen gemeinsamen Projektordner für die statische Analyse einzuschließen und beim Kompilieren nur ein einziges Verzeichnis zur Verwendung durch die Außenwelt auszugeben. Dies scheint einfach genug zu spezifizieren und ich habe Mühe zu verstehen, warum es nicht nur für den Benutzer schwierig ist, sondern aus der Perspektive der TS-Spezifikation anscheinend _verboten_.

Was ich hervorheben möchte, ist, dass der einzige Grund, warum diese Funktion nicht zulässig ist, darin besteht, dass der Compiler eine korrupte Absicht des Entwicklers annimmt. Wenn der Entwickler "outDir" auf ./src und der Compiler eine TS-Datei in ./test , _könnte_ er annehmen, dass diese Datei nicht ausgegeben werden muss (vorausgesetzt natürlich, dass es wird von keiner Datei in "outDir" referenziert).

Aber das tut es nicht. Es wird davon ausgegangen, dass der Entwickler diese Datei ausgeben _wollte_ und durch Inkompetenz oder Bosheit ein Unterverzeichnis angegeben hat, das sie nicht enthält. Mit anderen Worten, der Compiler hat die Möglichkeit, die Anweisungen des Entwicklers einem üblichen und vernünftigen Anwendungsfall zuzuordnen, und vergleicht ihn stattdessen mit etwas Absurdem und weigert sich, fortzufahren.

So wie es aussieht, sehe ich nicht einmal den legitimen Anwendungsfall für "outDir" . Ich gehe davon aus, dass es eine Projektstruktur unterstützt, in der sich tsconfig.json zusammen mit anderen Konfigurations- und Metadatendateien auf der obersten Ebene befindet und der Besitzer möchte, dass der kompilierte Ordner nur den darin verschachtelten Quellordner darstellt. (Stellen Sie nur sicher, dass keine dieser Metadateien mit .ts endet: das wäre absurd.)

Es scheint mir, dass das Design der Spezifikation benutzerfeindlich ist. Es gab einen Hinweis darauf, bei Starbucks ein Getränk zu bestellen und sich zu ärgern, wenn es nicht das war, was Sie erwartet hatten, obwohl die Zutaten auf der Speisekarte aufgeführt waren. Das ist soweit zutreffend, aber ich würde dieses Feature eher mit einem Hot-Dog-Stand vergleichen, der keine Hot Dogs verkauft.

Sicher, die irritierten Kunden hätten zurückgehen sollen und das große Schild sehen, das kühn verkündet, dass der Hot-Dog-Stand keine Hot Dogs verkauft. Aber wenn sich die Verwirrung häuft, bietet sich den Besitzern des Hot-Dog-Stands möglicherweise die Gelegenheit, darüber nachzudenken, wie sie den Kunden die Fähigkeiten ihres Produkts vermitteln.

Hmm, in Anbetracht dessen frage ich mich, ob es eine Art Invariante des Kernteams gibt, die diesem Problem zugrunde liegt:

Der gesamte Quellcode muss kompiliert werden. Wenn es nicht kompiliert ist, handelt es sich nicht um Quellcode.

Im Userland muss man das irgendwie überwinden. Ich weiß nicht, ob wir dies tun, indem wir die Definition des Quellcodes erweitern. TypeScript oder durch Erstellen einer zweiten Kategorie („unterstützender Code“, „Validierungscode“, „Peripheriecode“...). Dies wäre Code, von dem erwartet wird, dass er unter den gleichen Typdefinitionen wie der Quellcode arbeitet und der erfolgreich validiert werden muss, damit der Quellcode als korrekt angesehen wird, der jedoch nicht Teil der tatsächlichen Funktionalität des Programms in Bezug auf seine Schnittstelle ist.

Als Konsument von TypeScript fehlt mir das Verständnis für die besonderen Schwierigkeiten bei der Implementierung einer solchen Kategorie. Es scheint jedoch, als würde es genau zu "outDir" passen: Alles in "outDir" ist Teil des Quellcodes, alles außerhalb davon, aber innerhalb des Projektordners, ist Teil des unterstützenden Codes. Die Hauptsache, die dies nützlich/notwendig macht, ist das Aufkommen von ts-node, was bedeutet, dass ich diesen unterstützenden Code als separaten Schritt ausführen kann, völlig unabhängig von der Kompilierung; Und das möchte ich natürlich nutzen.

nicht implizit enthalten in irgendwelchen Eingabedateien, die dem Tool zur Verfügung gestellt werden

Dieses Problem wird genau verursacht, _weil_ der Benutzer implizit versucht, Dateien außerhalb von rootDir zu kompilieren. Sie haben dem Compiler im Grunde gesagt, "nur Dateien in diesem Verzeichnis kompilieren" und dann auf Dateien außerhalb dieses Verzeichnisses verwiesen. Der Compiler ist verwirrt und weiß nicht, wie er vorgehen soll.

/project/source/index.ts

import '../external.ts'

/project/tsconfig.json

{
  "compilerOptions": {
    "rootDir": "./source"
  }
}

In diesem Beispiel sagen Sie dem Compiler "Quelldateien befinden sich nur im 'source'-Verzeichnis". Dann verweist eine dieser Dateien auf eine Datei, die im Quellverzeichnis _nicht_ ist. TypeScript hat jetzt zwei widersprüchliche Anweisungen, eine besagt, dass nur Dateien im Quellverzeichnis kompiliert werden sollen, die andere besagt, dass Dateien außerhalb des Quellverzeichnisses kompiliert werden sollen.

@ MattiasMartens du include und rootDir . Wenn Sie /src und /test , wenn include src/* ist, können Sie keine Fehler über Dinge in /test sei denn, etwas von src fälschlicherweise etwas aus test importiert, worüber Sie sich freuen sollten!

Es ist nicht benutzerfeindlich oder antagonistisch, einen Mechanismus bereitzustellen, um aufzuschreiben, wie ein falscher Import in Ihr Programm aussieht, und einen Fehler auszugeben, wenn ein solcher falscher Import auftritt. Auch hier denke ich, dass dies von einem Missverständnis herrührt, was die Flags bedeuten - sie sind in erster Linie Opt-in-Durchsetzungsprüfungen, die Ihnen helfen überprüfen , ob Ihr Programm richtig konfiguriert ist.

Trotzdem!

Angesichts der Definition von rootDir , wenn TypeScript eine Datei außerhalb der angegebenen rootDir sieht, hat es einige Optionen:

• Geben Sie eine Datei über outDir (vorausgesetzt, dies ist überhaupt möglich!), was den Anweisungen des Benutzers zum Ausgabeort widerspricht
• Verarbeiten Sie die Datei, aber geben Sie sie nicht aus, da dies ohne andere Build-Schritte zu einem nicht funktionierenden Programm führt
• Einen Fehler ausgeben, weil das Projekt falsch konfiguriert zu sein scheint

Ich lehne die Vorstellung, dass das Ausgeben eines nicht funktionierenden Programms die Standardeinstellung sein sollte, nachdrücklich ab. Wenn die Funktionsanforderung hier einfach darin besteht, .ts Dateien außerhalb von rootDir als .d.ts , ist das vernünftig, es ist nur eine andere Sache als rootDir Bedeutung etwas anderes als rootDir . Wie würden Sie eine solche Flagge nennen?

@ MattiasMartens du include und rootDir . Wenn Sie /src und /test , wenn include src/* ist, können Sie keine Fehler über Dinge in /test sei denn, etwas von src fälschlicherweise etwas aus test importiert, worüber Sie sich freuen sollten!

Das stimmt. Ich habe mit include herumgefummelt und festgestellt, dass es in diesem Fall besser funktioniert, als ich dachte, auch mit den Tools von VSCode.

Ich würde immer noch wie Code zu haben , die auf der Kompilierung validiert wird , aber nicht auf der Kompilierung emittieren, was etwas ist , dass include nicht Abdeckung. Aber das ist eine separate Anfrage, die hier nicht erörtert werden muss.

Ich denke, dies kommt von einem Ort des Missverständnisses, was die Flags _bedeuten_ - sie sind in erster Linie _Opt-In-Erzwingungsprüfungen_, um Ihnen zu helfen, zu überprüfen, ob Ihr Programm richtig konfiguriert ist.

Ich bin dadurch verwirrt. Betrachten Sie rootDir eine Durchsetzungsprüfung für das Opt-in? Es beeinflusst, was schließlich ausgegeben wird, also ist es eindeutig nicht _nur_ eine Durchsetzungsprüfung.

Einige Flags, wie target , ändern drastisch, was ausgegeben wird – sie sind keine Durchsetzungsprüfungen, sondern Compileranweisungen. rootDir liest sich wie eine Compiler-Anweisung und wird wie eine solche dokumentiert.

Ich lehne die Vorstellung nachdrücklich ab, dass _ein nicht funktionierendes Programm ausgeben_ der Standard sein sollte.

Nach dem, was ich bisher über diesen Thread gelesen habe, scheint es einen breiten Konsens zu geben, dass ein Verweis von einer Datei innerhalb von rootDir auf eine Datei außerhalb von rootDir _ein Fehler_ sein sollte. Der Aspekt der Funktion, die ich und andere als frustrierend empfunden haben, ist, dass sie hier nicht aufhört, sondern tatsächlich einen Fehler auslöst, wenn sie im Projektordner TS-Dateien außerhalb von rootDir ob eine Datei in rootDir importiert sie oder nicht.

Es muss wiederholt werden: Ich setze rootDir auf den Ordner, in dem sich mein Quellcode befindet, der Compiler bemerkt anderen TS-Code im Projekt, der nichts mit dem zu tun hat, was in rootDir , und er hält an! Dieses spezielle Verhalten hilft mir nicht, meinen Code zu verstehen. Es ist einfach nervig.

Es ist wahr, dass das Verhalten aus der Perspektive der TypeScript-Definition von rootDir , wie in diesem Thread ausgeführt, vollkommen vernünftig ist, und jeder, der hierher gekommen ist, um seine Frustration darüber auszudrücken, liegt im Irrtum. Aber es ist aus der herkömmlichen, erwarteten Definition eines Root-Verzeichnisses nicht vernünftig. Ich sage Ihnen, dass ich in praktisch jedem Kontext, in dem ich ein Root-Verzeichnis anbiete, dem Programm frage , ob es absolut sicher ist, dass es nicht noch etwas anderes im Dateisystem gibt, das ich auch sein könnte Interesse an.

Definitionen können falsch sein. Sie können geändert werden. Aus Gründen der Abwärtskompatibilität ist es nicht erforderlich, Definitionen beizubehalten, sondern nur Funktionalität.

Wenn die Funktionsanforderung hier einfach darin besteht, .ts Dateien außerhalb von rootDir als .d.ts

Ich... glaube nicht, dass ich das will, aus so ziemlich den gleichen Gründen, aus denen ich möchte, dass der Compiler einen Fehler ausgibt, wenn etwas in rootDir Code von außerhalb importiert. Ich denke, der Inhalt eines rootDir wenn ich einen anbiete, vom umgebenden Code gekapselt werden.

Ich denke, der einfachste Weg, das Verhalten zu vermeiden, das ich und andere nicht wollen, besteht darin, Dateien außerhalb von rootDir implizit auszuschließen, wenn die Dateien in rootDir nicht auf sie verweisen. Wenn die Dateien in rootDir sie beziehen, soll ein Fehler ausgelöst werden, wie es derzeit ist.

Jeder Absatz dort scheint sich auf " rootDir sollte den Standardwert von include ändern " zu reduzieren, was vernünftig wäre, wenn wir diese Flags heute gleichzeitig hinzufügen würden, aber ist keine Build-Breaking-Änderung, die wir zu diesem Zeitpunkt vornehmen könnten. Obwohl wohl machen alle die Konfigurationsflags interact miteinander mehr erhöht kognitive Belastung anstatt verringert sie.

Vielleicht sollten wir einfach einen benutzerdefinierten Fehler ausgeben, wenn include nicht explizit festgelegt ist und eine eingeschlossene Datei außerhalb von rootDir .

Die Datei "tests/foo.ts" befindet sich außerhalb von rootDir 'src'. Haben Sie vergessen, ein "Include"-Muster festzulegen?

Gespeichert #33515

Ich hatte Probleme damit, auch in https://github.com/microsoft/TypeScript/issues/31757#event -2480427393

Das Zusammenspiel zwischen rootDir, include und exclude ist einfach so seltsam gestaltet.

Ich dachte immer, dass rootDir der Ordner ist, den der Compiler zu durchlaufen beginnt und dass zusätzliche Ordner (zB Herstellerordner) enthalten sind, auf die von rootDir verwiesen werden könnte.

Die aktuelle Definition ist höllisch seltsam und äußerst unintuitiv.

Ironischerweise ist das Verwirrende, dass sie nicht interagieren: Die Einstellungen beeinflussen sich nicht gegenseitig. include hat zu 100 % die Kontrolle darüber, was im Programm enthalten ist, und rootDir hat zu 100 % die Kontrolle über die Berechnung des Layouts von outDir .

Um ein weiteres Beispiel für das Problem hinzuzufügen, ist dies meine Ordnerstruktur:

tsconfig.json
package.json
src/index.ts

Ich habe in meiner tsconfig:

"rootDir": "src",
"outDir": "lib",

Und in meiner "index.ts" (src-Ordner)

import pkg from '../package.json'; // I read the package.json object

export class SomeClass {
  public version = pkg.version;
}

Ich _weiß_, dass sich die Datei "index.js" nach dem Build im Ordner "lib" befindet. Und ich _weiß_, dass die package.json 1 Ebene höher sein wird.
Ich denke nicht, dass Typescript meine Ordnerstruktur besser kennen sollte als ich und den Build unterbrechen. Es sollte einfach eine Warnung über einige Dateien außerhalb des RootDir-Ordners protokollieren, die nicht im Ausgabeordner enthalten waren.

@sebelga Ich würde das wahrscheinlich als Fehler betrachten - .json von außerhalb von rootDir zuzulassen wäre in Ordnung, da TS das nicht in den Ausgabeordner kopiert

@sebelga Ich würde dies wahrscheinlich als Fehler betrachten - das Zulassen von .json von außerhalb von rootDir wäre in Ordnung, da TS das nicht in den Ausgabeordner kopiert

Danke, stimmt nicht.. Wir haben einige spezielle Regeln für die Ausgabe von .json-Dateien... Wenn die Datei an derselben Stelle an sich selbst ausgegeben wird, wird sie nur dann nicht ausgegeben. In allen Fällen wird es ausgegeben (zB wenn --outDir angegeben wird, wird es in diesen Ordner ausgegeben)

@RyanCavanaugh Ich habe einen ähnlichen Anwendungsfall wie @sebelga, bei dem ich zur console.log aus der Versionsnummer von package.json herausholen möchte.

Meine Lösung war also, mein "rootDir": "." zu ändern, dann habe ich dies inklusive

"include": [
    "src",
    "typings"
  ]

Und da die Datei package.json Ordner lib (built) enthalten ist, der einen "src"-Unterordner enthält, habe ich ein Bash-Skript geschrieben, das direkt nach dem Build ausgeführt wird, um die Dinge zu bereinigen.

#!/bin/bash

rm lib/package.json
mv $(pwd)/lib/src/* $(pwd)/lib
rm -rf lib/src

Es funktioniert, kommt mir aber ziemlich hackig vor.

@sebelga Hast du .ts Dateien im typings Ordner? Wenn nicht, wäre es legal, rootDir auf src und das Skript zu überspringen.

@sebelga Anstelle von const { version } require('../../package.json') oder import { version } from 'package.json') hast du mal versucht, so etwas zu tun:

import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');

TypeScript kümmert sich nicht darum, dass es rootDir diese Weise außerhalb von

https://github.com/sindresorhus/load-json-file

Wenn Sie vermeiden möchten, dass alle ../.. hartcodiert werden, können Sie Folgendes versuchen:
https://github.com/sindresorhus/read-pkg-up

@RyanCavanaugh Ich kann es nicht wie oben erwähnt auf "src" setzen. Ich importiere "package.json" außerhalb unserer src ( import pkg from '../package.json'; ) und tsc lässt dies nicht zu.

Danke, dass du das

Ich habe Typoskript gesagt, dass sich meine Quelle in einem bestimmten Ordner befindet (über rootDir)

Das ist nicht das, was rootDir bedeutet! rootDir bedeutet "Diesen Ordner als relative Basis für die Berechnung der Pfade in outDir ". _Welche Dateien sind Teil Ihrer Zusammenstellung_ ist eine separate Frage, die mit files und/oder include / exclude beantwortet wird

@RyanCavanaugh Aber es ist das, was rootDir bedeuten sollte , und darum geht es in diesem Thema.

Ich bin nicht so gut darin, meine Fassung zu bewahren, wenn ich Probleme sehe, die seit 2016 offen sind und die wahrscheinlich sehr behoben werden könnten, ohne neue Probleme für bestehende Benutzer einzuführen, indem man eine neue "compilerOption" einführt, um den Compiler wissen zu lassen, dass er den Fehler ignorieren kann in einem bestimmten Anwendungsfall.

Dafür entschuldige ich mich. Ich kann nicht anders, weil man sich darauf verlässt, einen guten Service zu bieten, aber ich stoße gelegentlich auf solche Themen-Threads. Warum ist es für die Autoren von TypeScript so schwierig, ein einfaches Konfigurationsflag zu implementieren?

Ich glaube nicht, dass es daran liegt, dass die Entwickler faul sind oder nicht helfen wollen. Ich glaube nicht, dass hier irgendjemand ein schlechter Mensch ist, außer mir selbst.

Es ist dieser Konflikt, diese Debatte, die seit Jahren über die scheinbare Definition der Eigenschaft "rootDir" geführt wird. Und was tun bei diesem Problem?

Die Leute werden in diese Debatte hineingeworfen, weil sie glauben, dass sie Recht haben. Ja, "rootDir" dient als Basisverzeichnis für den Quellcode. Ja, der Fehler ist gültig.

Das zugrunde liegende Problem besteht jedoch weiterhin. Meine Tools kompilieren den Code perfekt, aber meine IDE zeigt diesen Fehler auf meinem Bildschirm an. Es ist eine Perversion. Ich will, dass diese roten Linien weg sind. Meine Dateien enthalten keine Fehler. Und wenn doch, sollte ich mich auf diese konzentrieren, anstatt mich von diesen Nicht-Themen ablenken zu lassen.

Ich möchte nur diese Fehlermeldung unterdrücken. Ich glaube, das wollen die meisten von uns. Ich weiß nicht, ob es hier noch andere Fälle gibt und vielleicht gibt es Leute, die sich dazu äußern möchten.

Können wir bitte zusammenarbeiten und dieses Problem lösen? Es würde mich so glücklich machen, wenn diese roten Linien verschwunden wären...

@nullquery Wenn tsc funktioniert, aber Ihre IDE Ihre roten Squigglies anzeigt, bedeutet dies, dass Ihre IDE nicht dieselbe Compiler-Version oder -Konfiguration wie tsc .

@nullquery- Datei einen Fehler, der zeigt, wie das Problem reproduziert werden kann, und wir werden es entweder beheben oder Ihnen mitteilen, was mit Ihrer Projektkonfiguration nicht stimmt

Im Anschluss an die Problemumgehung von

tsc --module commonjs --target ESNext --outDir ./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true

Anwendungsbeispiel hier.

Boundation wendet es automatisch für Sie an.

Die Lösung heißt Projektreferenzen .

Um dies zu verwenden, bearbeiten Sie Ihre Datei "tsconfig.json" und fügen Sie diese am Ende der Datei (außerhalb der "compilerOptions") hinzu:

"references": [
    { "path": "../common" }
]

Dadurch können Sie auf Dateien im Ordner "../common/" (und allen Unterordnern) verweisen.

Meine frühere Verwirrung rührte von der Tatsache her, dass IntelliJ und meine unbefleckte gulp-typescript Aufgabe mir unterschiedliche Ergebnisse lieferten, obwohl ich dieselbe Datei "tsconfig.json" verwendet habe.

Es stellt sich heraus, dass "gulp-typescript" aus irgendeinem Grund versucht, die Kompilierung nach besten Kräften durchzuführen.

Ein Fehler in TypeScript (wie let z: number = '' ) wird in IntelliJ gemeldet, aber "gulp-typescript" kompiliert es gut.
Nur JavaScript-Syntaxfehler (wie let 1z = '' ) werden durch "gulp-typescript" gekennzeichnet.

Wenn Sie also ein "gulp-typescript"-Benutzer sind, kann ein solches Problem je nach Ihrer Version von "gulp-typescript" und Ihrer Konfiguration auftreten. (Ich verwende zum Zeitpunkt des Schreibens die neueste Version, aber ich gehe davon aus, dass jemand aus der Zukunft dies liest. Ich hoffe, die Zeiten sind besser für Sie.)

Ich weiß, dass die Verwendung von Projektreferenzen irgendwo in dieser Lawine von Antworten vergraben ist, aber es wäre besser gewesen, wenn dies besser dokumentiert worden wäre.

Die Top-3-Ergebnisse für "TS6059" bei Google führen alle zu GitHub-Problemen. Es wäre mir viel klarer gewesen, wenn es eine Seite gäbe, die diese häufigen Fehler und ihre Lösungen dokumentiert.

@MicahZoltu Ist das etwas, das angegangen werden kann? Soll ich eine neue Ausgabe machen oder geht das schneller, wenn sie intern zwischen den Hauptmitwirkenden besprochen würde?

(FWIW Ich bin nicht Teil des TypeScript-Teams)

Im Allgemeinen rate ich davon ab, path s zu verwenden, es sei denn, Sie müssen es unbedingt. Ich glaube, sein Zweck besteht darin, die Kompatibilität mit älteren JS-Projekten mit seltsamen Abhängigkeitsstrukturen zu ermöglichen, aber ich glaube nicht, dass es für neue Projekte gedacht ist Sie haben die Möglichkeit. Ich benutze es nicht persönlich, daher kann ich bei Problemen, die Sie möglicherweise damit haben, nicht wirklich helfen, aber ich habe gesehen, wie viele Leute damit zu kämpfen haben und die Lösung lautet normalerweise "Hör auf, es zu verwenden".

Was gulp-typescript angeht, so klingt es, als ob sich die Version von TSC, die von gulp-typescript verwendet wird, von der Version von TSC unterscheidet, die von IntelliJ verwendet wird. Wenn Sie Symptome wie von Ihnen beschrieben sehen, ist dies normalerweise das Problem (der andere ist, dass sie nicht dasselbe tsconfig.json ).

Die von "gulp-typescript" verwendete Version sollte identisch sein; beide Versionen werden von node_modules . Ich habe verschiedene Möglichkeiten ausprobiert, Fehler zu erkennen und die damit verbundenen Einstellungen zu ändern (einschließlich des Herumspielens mit den verschiedenen "Reportern", die von "gulp-typescript" bereitgestellt werden, und des Versuchs, Einstellungen zu überschreiben, um mehr Fehler auszugeben. Nichts scheint zu funktionieren.

Es ist aber in Ordnung. Solange mir IntelliJ Fehler ausgibt, akzeptiere ich gerne, dass die Gulp-Aufgabe sie ignoriert.

Ich bin kein Fan davon, meine Methode zugunsten der bevorzugten Methode der Woche zu überarbeiten. Die Projektstruktur, die ich habe, macht für mich Sinn. Es hält alles enthalten und gibt mir die Flexibilität, Dinge in mehrere Komponenten aufzuteilen.

Ich glaube nicht daran, "Kompatibilität aus Legacy-Gründen zuzulassen" und insbesondere nicht, wenn es um Projektreferenzen geht. Es _muss_ möglich sein, auf Dateien außerhalb von rootDir zu verweisen, oder Sie haben einfach nicht die Freiheit, die Projektstruktur auf eine für Sie und Ihr Team sinnvolle Weise zu definieren.

Als ich anfing, mit TypeScript zu arbeiten, stieß ich auf zahlreiche Probleme. Darunter:

• Für die Einbindung von JavaScript-Dateien schien damals AMD die Lösung zu sein. Die Website klang offiziell und es gab online viele Beispiele von AMD im Produktionseinsatz. Aber anscheinend war Webpack das neue große Ding und so funktionierten einige Projekte in einer AMD-Umgebung einfach nicht. Lektion gelernt: Nicht jeder wird die neue Methode übernehmen, also sind Sie immer am Arsch.

• Der Weg von TypeScript zum finalisierten minimierten JavaScript (mit Quellzuordnungen) war mir nicht klar. Zu dieser Zeit waren mehrere verschiedene Methoden verfügbar, aber keine von ihnen schien damals nativ mit "tsconfig.json" -Dateien und/oder meiner IDE zu funktionieren. Lektion gelernt: Wenn Sie wollen, dass etwas richtig gemacht wird, müssen Sie es selbst tun; Verlassen Sie sich nicht darauf, dass andere die Arbeit für Sie erledigen, egal wie gut sie meinen, niemand ist perfekt und niemand kann _Ihren_ Arbeitsplatz vorhersagen.

• Es gab eine benutzerdefinierte Sache, die ich wollte: eine Möglichkeit, den Inhalt von HTML-Dateien zur Aufnahme in ein JavaScript-Wörterbuch zu konvertieren. Dies hätte mein einziger Stolperstein sein sollen, aber am Ende stellte sich heraus, dass dies eines der einfacher zu schreibenden Skripte war.

Am Ende musste ich mein eigenes Gulpfile entwickeln, um alles zu handhaben. Es macht folgendes:

• Kopiert die minimierten JavaScript-Dateien zur Verteilung aus dem Ordner node_modules in mein Webroot. Es klingt einfach, aber fast jede JavaScript-Bibliothek, die ich einbinden wollte, hatte einen anderen Ort, an dem sie ihre minimierten JavaScript-Dateien speicherten. Es gab keine Konfiguration, keinen klaren Pfad zu den Dateien. Am Ende musste ich für jede JavaScript-Bibliothek, die ich einschließen wollte, separate Skripte schreiben. Es funktioniert, vorausgesetzt, der Speicherort ändert sich in zukünftigen Versionen nicht, aber wenn dies der Fall ist, kann ich das Kopierskript jederzeit ändern.

• Kompiliert TypeScript gemäß der lokalen Datei "tsconfig.json", die separate Dateien in einem Ausgabeverzeichnis generiert (mit outDir ), damit ich sicher sein kann, dass TypeScript in meiner IDE genauso kompiliert wird wie in Gulp (hahahahaha!), verwendet dann das "Rollup"-Plugin, um diese Dateien in eine einzelne JavaScript-Datei zu komprimieren, und führt dann UglifyJS aus, um diese Datei zu verkleinern, während gleichzeitig eine Quellzuordnung beibehalten wird, die der ursprünglichen TypeScript-Datei zugeordnet ist.

• (Benutzerdefinierte Aufgabe) Generiert eine JavaScript-Datei mit einem Wörterbuch namens html_templates für jede HTML-Datei im TypeScript-Quellstamm und legt sie als minimierte JavaScript-Datei in meinem Webroot-Ordner ab.

Es mag elegantere Wege geben, aber nachdem ich von einem Open-Source-Projekt zum nächsten gesprungen war, hatte ich genug davon, zwischen den Lösungen zu jonglieren, die jeder von ihnen anbot.

Der Ansatz, den ich gewählt habe, funktioniert, er ist einfach zu verstehen (besonders jetzt, da ich verstehe, dass "Schluck-Typoskript" etwas anderes macht) und ich werde ihn wahrscheinlich noch jahrelang verwenden.

Die beste Lösung ist eine, die Sie selbst verstehen. Obwohl dies niemandem hilft, der versucht, mir zu helfen (was ich sehr schätze! die Hilfe meine ich, nicht die Verwirrung), kann ich aus Erfahrung sprechen, dass mit _jeder_ Lösung immer etwas nicht stimmt, also ist es besser, bei etwas zu bleiben Sie besitzen sich selbst als etwas, das von einem multikulturellen Team unterschiedlicher Überzeugungen, sexueller Orientierungen und Geschlechtsidentitäten entworfen, entwickelt und produziert wird .

tl; dr Bitte brechen Sie die Projektreferenzen nicht ab. Das brauche ich, damit mein Werkzeug funktioniert. Danke schön

Ich habe es aufgegeben, das TS-Setup für mehrere Projekte richtig einzurichten und mache einfach tsc -w in jedem Projekt und npm link , und dann können Sie die Komplexität von Multiprojekt-tsconfig einfach ignorieren und einfach auf andere verweisen Projekt als wäre es einfach node.js Abhängigkeiten in node_modules .

Aber heute habe ich in einem Projekt das Ziel von es5 auf es6 geändert und es wird nicht mehr kompiliert, weil File '.../lib.ts' is not under 'rootDir' .

Dateistruktur:

/app
 - tsconfig.json // rootDir = "."
 - app.ts (

/app/node_modules/lib
 - tsconfig.json // rootDir = "."
 - lib.ts
 - lib.js
 - lib.d.ts

Warum kümmert sich tsc in /app um die Datei /app/node_modules/lib/lib.ts ? Es sollte diese Datei überhaupt nicht verwenden. Es gibt /app/node_modules/lib/lib.js und /app/node_modules/lib/lib.d.ts kompiliert.

Wenn /app/node_modules/lib/lib.ts gelöscht wird - Überraschung - es kompiliert gut.

@alexeypetrushin kannst

• https://github.com/unional/standard-log
• https://github.com/mocktomata/mocktomata

import * as pkg from '../package.json';

NÖ. Und es gibt keine Möglichkeit, diesen Fehler zu deaktivieren, den ich finden kann.

@SephReed : Ich habe 200 sehr einfache Lösung zum Importieren von ../package.json beigetragen. Alles, was Sie tun müssen, ist eine typings.d.ts Datei mit folgendem Inhalt in das gleiche Verzeichnis wie package.json zu legen:

declare module '*.json';

Ich habe keine Ahnung, wie das funktioniert, aber ehrlich gesagt ist es mir egal. Zu diesem Zeitpunkt war TS für sich selbst da, nicht für mich.

Ich habe überrascht, dass dies eine so hitzige Debatte ist. Aber ich verstehe die Begründung. Für mich habe ich natürlich den Quellordner, aber ich habe auch Build-Skripte außerhalb dieses Ordners, die nicht kompiliert werden sollen, aber definitiv Typunterstützung enthalten, denn seien wir ehrlich, Ihr bester IntelliSense ist TypeScript.

repo/
⊢ config/  << provide TS support, but don't build this directory
  ⨽ webpack.config.ts 
⊢ scripts/  << provide TS support, but don't build this directory
  ⨽ release.ts
⊢ src/        << build this directory
  ⨽ example.ts
⨽ tsconfig.json

Also verwende ich "rootDir": "src" , um sicherzustellen, dass die Dateien in dist und nicht in dist/src . Aber natürlich beschwert sich TypeScript gerne über dieses Setup, aber da ich Webpack verwende, ist es für mich kein Fehler.

Ich habe endlich verstanden, was dieses Flag genau bedeutet, ohne mehrere Kommentare, die es nicht klarer machen. Prost einfach damit.

Die Optionen, die Ordner und Dateien für tsc festlegen, um Komplimente zu berücksichtigen: "files", "include", "exclude".

Wofür verwenden Sie dann "rootDir"?
rootDir ist das Stammverzeichnis der Verzeichnisstruktur (Hierarchie) zu Ihren Quelldateien, die tsc verwendet, um dieselbe Verzeichnisstruktur ab dem Verzeichnis tsconfig.json oder "outDir", falls angegeben, auszugeben. Dies ist also nicht der Pfad, den tsc als Basispfad für "outDir" verwendet. "outDir" ist nur das Root, das tsc Ausgabedateien ausgibt.
Nehmen wir zum Beispiel an, Ihr Java-Projekt hat diese Verzeichnisstruktur.

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

Wenn Sie "include" und "rootDir" wie unten angegeben festlegen, generiert tsc die Ausgabe als:

"include": "src/main/resources/static/ts" *
"rootDir": "." *

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.js *
          test.ts

Wenn Sie auch "outDir" wie unten angegeben festlegen, generiert tsc die Ausgabe als:

"include": "src/main/resources/static/ts"
"rootDir": "."
"outDir": "build" *

- build
  - src
    - main
      - resources
        - static
          - ts
            test.js *
- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

Wahrscheinlich wollten Sie dies, indem Sie die Option "rootDir" setzen und die Option "outDir" wie unten beschrieben ändern.

"include": "src/main/resources/static/ts"
"rootDir": "src/main/resources/static/ts" *
"outDir": "src/main/resources/static/js" *

- src
  - main
    - java
    - resources
      - static
        - js
          test.js *
        - ts
          test.ts

Wenn Sie also die Option "rootDir" gesetzt haben, die den Geltungsbereich von Dateien außer der Option "exclude" nicht abdeckt, schlägt die Erstellung von tsc fehl, da dies mit dem Zweck der Option "rootDir" nicht sinnvoll ist.

Ja, es ist eine völlig schlechte Benennungspraxis. Es hätte nur "rootOfStructureOfInputs" oder so sein sollen. Außerdem sollte "outDir" nur "rootOfOutputs" sein.

Was Sie auf der SS sehen, ist kein WebStorm-Problem - es kommt vom TS DevServer.
Der zweite empfohlene Import ist Mist. Es nimmt aus dem Quellordner "Kommunikation" auf. Ich weiß nicht, wer zum Teufel das wollen soll. Das Kompilieren einer Datei mit einem solchen Import führt zu einer Reihe von Problemen.

Ich habe auch versucht:

"exclude": ["lib", "node_modules",
        "..", "../..", "../../..", "../../../..", "../../../../..", "../../../../../.."
    ]

Hat das Problem auch nicht gelöst

@mhegazy Sie haben dieses Problem mit "Funktioniert wie beabsichtigt" bezeichnet, aber das stimmt nicht. Wie Sie in meinem Screenshot sehen können, stellt tsc-server Dateien außerhalb meines rootDirs (in diesem Fall mobiservice/src) als Importvorschlag bereit. Für mich sieht das nach einem Bug aus...