Tslint: keine impliziten Abhängigkeiten: Pfadzuordnung unterstützen

Ich denke, wenn ein Import in node_modules nicht in etwas aufgelöst wird, sollte diese Regel ihn ignorieren.

Die Regel versucht nicht, die Module aufzulösen. Das würde bedeuten, dass Sie alle Abhängigkeiten installiert haben müssen, was mit peerDependencies und optionalDependencies nicht wirklich möglich ist. Mit der aktuellen Implementierung können Sie einen neuen Klon linten, ohne etwas zu installieren. Ich denke, das ist, was die meisten Codequalitätstools tun.

Soweit ich weiß, gibt es Pfadzuordnungen nur zur Kompilierzeit. Zur Laufzeit benötigen Sie noch das installierte Modul für node / webpack / was auch immer, um es korrekt abzuholen.
Das bedeutet, dass Pfadzuordnungen nur relevant sind, wenn Sie Nur-Typ-Importe haben, die während der Kompilierung entfernt werden. In diesem Fall ist die Regel wahrscheinlich nicht die richtige Wahl für Sie.

In unserem Fall gibt es im Allgemeinen überhaupt kein package.json , also sollten wir diese Regel dann einfach deaktivieren. Vielen Dank!

In meinem Fall "importiere" ich separate Typoskript-Projekte, an denen ich gleichzeitig arbeite, indem ich die Pfadzuordnung verwende:

"compilerOptions": {
    ...
    "paths": {
        "tsbase": ["../tsBaseProject/src"],
        "tslibrary": ["../tsProjectLibrary/src"]
    }
}

damit ich sie im Projekt wie Module verwenden kann.
Gibt es eine Möglichkeit, sie auf die Whitelist zu setzen?

@marcoqu Pfadzuordnungen sind nur zur Kompilierzeit relevant. Zur Laufzeit müssen diese Module in node_modules vorhanden sein. Ich schlage vor, sie entweder als dependencies oder als peerDependencies zu Ihrem Paket hinzuzufügen.json

Wenn ich die Hauptquelle kompiliere, die die sekundären Projekte "importiert", wird alles zu einem einzigen Bundle kompiliert, als wären es tatsächliche Ordner im Projekt. Ich brauche sie nicht im Ordner node_modules.
Um es klar zu sagen, in den sekundären Projektordnern habe ich tatsächliche .ts-Dateien, nicht nur die Typdeklarationen.

+1 für das Hinzufügen einer Whitelist wie bei no-submodule-imports

Wir haben auch den Fall, dass wir den Fall verwenden, dass wir einen Pfadalias '~' zum Basisverzeichnis definieren, um relative Importe zu vermeiden. Dieser Alias ​​wird später von Webpack, Fuse-Box usw. aufgelöst. Ab 5.8 spuckt tslint deswegen viele falsche Fehler aus...

Was er gesagt hat ^^

Nach dem Upgrade habe ich jetzt Hunderte dieser Fehler aus den gleichen Gründen wie oben beschrieben. Eine irgendwie sinnlose Regel.

Diese Regel funktioniert nicht, wenn wir Alias ​​für unseren eigenen Quellcode verwenden (nicht um aus npm-Paketen zu importieren). Es ist sehr nützlich, den absoluten Pfad anstelle des relativen Pfads zu verwenden.
In unserer tsconfig.json müssen wir für eine eckige Anwendung nur Folgendes hinzufügen:

"compilerOptions": {
  ...
  "baseUrl": "./src",
  "paths": {
    "~/env": ["environments/environment"],
    "~/*": ["app/*"]
  }
}

Dann können wir Importe durchführen wie:

import {FooService} from '~/core';
import {Environment} from '~/env';

Möglicherweise sollten wir dieses Problem erneut öffnen, um diesen Fall zu lösen (es werden keine node_modules benötigt, nur die Datei tsconfig.json).
Ich schätze diese Regel, daher wird es bedauerlich sein, sie zu deaktivieren.

@andy-ms bitte überdenken Sie die unterstützenden Pfade (wir verwenden sie ausgiebig mit nx-Arbeitsbereichen). Dies ist eine wirklich nützliche Regel, aber im Moment bin ich gezwungen, sie zu deaktivieren.

Ich habe versucht, den Quellcode durchzusehen, und die Fehlerbehebung müsste irgendwo in diese Richtung gehen . Ich habe auch überprüft, wie Typescript damit umgeht, und ich habe es bis zu dieser Funktion verfolgt . Es ist definitiv keine leichte Aufgabe, diese Logik zu kopieren. Ich bin mir nicht sicher, ob diese Funktion wiederverwendet werden kann, es gibt eine Reihe von Argumenten, bei denen ich mir nicht sicher bin.

Ich würde mir sehr wünschen, dass dies auch behoben wird. Die Pfadzuordnung ist eine hoch geschätzte Funktion. Ich habe auch versucht, verknüpfte Module als Problemumgehung zu verwenden, aber auch diese werden nicht unterstützt.

Ich habe eine Problemumgehung gefunden, die das Problem etwas für mich löst, aber es ist nicht sicher, ob es für jeden funktioniert oder ob es überhaupt wartbar ist. Die Lösung sieht jedenfalls wie folgt aus:

Fügen Sie ein gefälschtes Paket zu optionalDependencies mit dem Namen der Pfadzuordnung von tsconfig.json und installieren Sie Abhängigkeiten mit npm install --no-optional . Dies funktioniert leider nicht mit yarn --ignore-optional - es schlägt immer noch fehl, das Paket abzurufen.

Also, mit Pfaden in tsconfig.json sieht ungefähr so ​​aus:

    "paths": {
        "~/*": ["src/*"],
        "some-path/*": ["whatever/*"]
    }

Und optional in package.json wie folgt:

    "optionalDependencies": {
        "~": "tslint-hack",
        "some-path": "tslint-hack"
    },

Es sollte möglich sein, Produktions- und Entwicklungsabhängigkeiten mit npm install --no-optional zu installieren. Dies setzt natürlich voraus, dass Sie keine optionalen Abhängigkeiten installieren müssen. Erwähnenswert ist auch, dass ich es nicht mit @ als Paketnamen zum Laufen gebracht habe.

Wenn Sie sich für diesen Hack entscheiden, kann es wahrscheinlich schlau sein, eine .npmrc Datei zum Projektstamm hinzuzufügen, mit optional=false konfiguriert, damit Sie npm install ohne --no-optional Flag.

Eine andere Lösung, die funktionieren _sollte_, besteht darin, tatsächlich ein Paket mit dem gewünschten Namen zu erstellen und es mit Verdaccio oder ähnlichem in einer privaten Registry zu veröffentlichen. Ich glaube, dass es möglich ist, private Registrierungen pro Modul mit .npmrc oder .yarnrc zu konfigurieren, und sollte daher in Bezug auf die Wartbarkeit besser sein. Nichts davon wird jedoch getestet.

Ich hoffe, dies kann ein wenig für diejenigen helfen, die diese Tslint-Regel verwenden und ihre Modulauflösungen beibehalten möchten. Aber es ist kein Ersatz für eine ordentliche Lösung..

Dieses Problem tritt auch auf, was dazu führt, dass das Sonar dies fälschlicherweise als Code-Geruch kennzeichnet.

Ich denke, dies ist eine gültige Anfrage, da es bei tslint nur um Typoskript geht und Pfade eine gültige (und wichtige) Typoskripteinstellung sind.

Was ist, wenn ich package.json in einem anderen Verzeichnis als tslint.json ?

- web
    - package.json
    - ClientApp
        - tslint.json

Ich arbeite an einem ähnlichen Setup und erhalte aufgrund dieser Regel in fast allen Dateien Fehler. Irgendeine Lösung dafür?

Der Weg, den ich gefunden habe, um dieses Problem zu umgehen, ist die Verwendung der folgenden Konfigurationsoption.

"no-implicit-dependencies": [true, ["src", "app", "~"]]

Die bereitgestellten Pfade werden auf eine Whitelist gesetzt. Dies bedeutet natürlich eine Duplizierung, aber es ist eine schnelle Lösung, wenn Sie nach einer suchen.

Für diejenigen von uns, die @ Symbole als Präfixe für benutzerdefinierte Pfade verwenden, habe ich eine PR erstellt, um einen kleinen Fehler mit der aktuellen Implementierung #4192 zu beheben

"no-implicit-dependencies": [true, ["@src", "@app", "~"]]

@ifiokjr Ich habe @ als meinen src-Alias ​​verwendet, also sahen meine Importe aus wie @/components
@ als ignorierter Pfad festgelegt werden, da versucht wurde, @/components als ganzes Modul zu importieren, anstatt zuerst @ aufzulösen.

Ich habe meinen Alias ​​in ~ geändert und die obige Zeile in meinem Tslint verwendet, um das Problem zu lösen