Tslint: Funktionsanfrage: Ausschließen von Dateien für eine bestimmte Regel zulassen

Warum verwendest du nicht einfach:

/* tslint:disable:class-name */
// your generated file here

Funktioniert das nicht?

Das könnte in der Tat verwendet werden, um es zum Laufen zu bringen, aber ich habe diese Feature-Anfrage gestellt, um zu vermeiden, den TypeScript-Generator zu ändern (oder den Generierungsprozess zu verkomplizieren, indem generierte Dateien mit Tslint-Hinweisen vorangestellt werden).
Die Verwendung von Platzhaltern kann auch vorteilhaft sein, um bestimmte Regeln deklarativ nur auf bestimmte Arten von Quellen (main/unitTests/e2eTests) aus der tslint-Konfiguration anzuwenden, nicht auf jede einzelne Datei.

Was denken Sie?

Wenn Sie keine Kommentare in die Datei einfügen möchten, übergeben Sie die Datei einfach nicht zum Linting an tslint , oder?

Es fühlt sich zu schwer an, an anderer Stelle weitere Optionen hinzuzufügen, wenn es mindestens zwei Möglichkeiten gibt, einen (teilweisen) Dateiausschluss zu erreichen

Wenn Sie keine Kommentare in die Datei einfügen möchten, übergeben Sie die Datei einfach nicht zum Linting an tslint, nicht wahr?

Genau das habe ich getan, aber jetzt wird keine der Regeln gegen ausgeschlossene Dateien geprüft.

Es fühlt sich zu schwer an, an anderer Stelle weitere Optionen hinzuzufügen, wenn es mindestens zwei Möglichkeiten gibt, einen (teilweisen) Dateiausschluss zu erreichen

Ja, das habe ich als Antwort erwartet ;) Ich hatte auch einige Zweifel - zumindest an der Umsetzung (die ich so einfach wie möglich gehalten habe).

In Wirklichkeit wäre es von Vorteil, wenn Sie dies implementieren könnten, wenn Sie Konstanten für Einschluss- und Ausschlussmuster definieren könnten, damit Sie nicht dasselbe Einschluss-/Ausschlussmuster in alle Regeln kopieren müssen, in denen Sie filtern möchten die gleichen Dateien... Ich dachte, es wäre vielleicht nicht sinnvoll, das Beispiel komplizierter zu machen, aber ich hatte so etwas im Sinn:

{
    "constants": {
        "generatedFilesGlob": "**/generated.ts",
        "someOtherConstant": "some other value, that could be reused",
        ...
    },
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ {"exclude": "generatedFilesGlob"}, "arg1", "arg2", "arg3"],
        ...
    }
}

aber das würde das Parsen der Konfigurationsdatei erschweren. Das brachte mich dazu, darüber nachzudenken, zusätzlich zu json-Dateien auch js-Dateien für die Konfiguration zu unterstützen. Zum Beispiel:

const generatedFilesGlob = "**/generated.ts";
const allExceptGenerated = {exclude: generatedFilesGlob};
module.exports = {
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        "another-rule-with-the-same-exclude-pattern": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        ...
    }
}

Die Verwendung von JavaScript-Dateien mit Modulen (wie gulp) hat einen weiteren Vorteil - es ermöglicht das Kommentieren und ist bei Kommas nach dem letzten Element im Array oder der Eigenschaft im Objekt nicht so streng.

@atsu85 interessantes Problem, aber wie @myitcv angedeutet hat, tslint.json einzuführen , da die Konfigurationsdatei zusätzlich .json Dateien auch .js Dateien für die Konfiguration akzeptieren sollte. Ich denke, das würde Ihnen helfen, den Anwendungsfall anzugehen – Sie könnten zwei tslint Build-Aufgaben einrichten (eine für Ihre regulären Quellen, eine für generierte Quellen) und die Regel class-name in einer programmgesteuert deaktivieren von ihnen in derselben tslintConfig.js Datei.

Eingereicht Nr. 1065 für die Unterstützung von .js Konfigurationsdateien

Fair genug, ich werde dieses Problem zugunsten von nur js-Konfigurationsdateien schließen

Ich habe einen Anwendungsfall dafür, der Sinn machen könnte. Ich habe Testdateien (*.spec.ts), mit denen ich die meisten meiner Typescript-TSLint-Regeln teilen möchte, da die guten Codierungspraktiken auch für meine Tests gelten.

Ich teste jedoch einige Konstanten, die für die Regel "magische Zahlen" konfiguriert sind, um keine 5 in meinem Code zu haben:
(Foo.substr(0,5);
aber stellen Sie sicher, dass es eine Konstante ist
(Foo.substr(0,CONSTANT.FIVE);

Daher hat mein Testfall für meine const, der aus einer gemeinsamen Datei enthalten ist, einen Test, um sicherzustellen, dass const FIVE = 5 immer gesetzt ist. Der Test hat dann expect(CONSTANTS.FIVE).toBe(5); die TSLint-Prüfung nicht bestanden, da die magische Zahl im Test verwendet wird. Obwohl ich nicht alle Konstanten auf diese Weise teste, möchte ich diese numerischen Einstellungen überprüfen, um sicherzustellen, dass sie sich nicht ändern, da sie die spezifische Größe beibehalten sollen.

Ich könnte zwei verschiedene TSLint-Konfigurationen verwenden, aber ich möchte wirklich vermeiden, dass sie nicht mehr synchron sind oder beim Hinzufügen einer neuen Regel dies an mehreren Stellen tun müssen.

Ich kann /* tslint:disable : no-magic-numbers*/ für die eine Datei für diese spezifischen Tests

Ich habe einen ähnlichen Anwendungsfall wie @Chowarmaan.

Ich habe Testdateien *.test.ts in denen ich Dev-Abhängigkeiten verwende, zB enzyme .
In tslint.json ich die Regel no-implicit-dependencies aktiviert und möchte diese Regel nur für *.test.ts deaktivieren. Diese Testdateien befinden sich nicht alle im selben Ordner, also muss ich jetzt Folgendes einfügen:

/* tslint:disable:no-implicit-dependencies */

am anfang bei jeder testdatei was nervig ist

Dies ist ein ähnliches Problem, auf das ich sowie bei @RomanGotsiy stoße, bei dem Sie oben in den Testdateien

Dies. 100%. Habe dieses Problem mit einem Monorepo, bei dem die Testabhängigkeiten im Arbeitsbereich aufgelistet sind, so dass tslint über no-implicit-dependencies weint. Es muss mit einer einzigen Konfigurationsdatei durchgeführt werden, damit IDE-Linting weiterhin funktioniert

Ich denke, dieses Problem hängt auch mit #3447 zusammen

Ich werde diesen veralteten Thread auch ergänzen. Ich bin dabei, einen NgRx-Store in meinem Angular-Projekt zu implementieren. AOT build schreit mich an, wenn ich eine const-Referenz auf eine Funktion exportiere ...

export const reducer = ( state = initialState, action: CurrentAction): CurrentState => {...}

Gibt mir einen Function expressions are not supported in decorators in 'reducers' Fehler. Das Problem tritt aufgrund unserer Linting-Regeln auf. Wir haben es ermöglicht , speziell die only-arrow-functions Regel über das Projekt ... es wäre wunderbar , in Mustervergleich auf dem hinzuzufügen ausschließen zu sagen Ausschließen von Dateien von *.reducer.ts für diese spezielle Regel als Beispiel aber erlauben es soll für jede andere Datei intakt bleiben.

So wie es ist, ist es mühsam, diese Zeile für jede Reducer-Datei am Anfang der Datei hinzuzufügen. Es scheint nur, dass es einen besseren Weg geben sollte.

Necrobumping das auch. Ich versuche, tslint-microsoft-contrib zu einem Vue-Projekt hinzuzufügen und eine Reihe seiner Regeln bombardieren .vue-Dateien; Dies könnte eine nützliche Problemumgehung für Probleme wie dieses sein, bevor die Regelautoren diese Fehler ausbügeln - falls sie es jemals wünschen. So wie es aussieht, ist es in der Tat mühsam, einen Kommentar hinzuzufügen, um eine Reihe von Regeln in absolut jeder Vue-Datei, die ich schreibe, zu deaktivieren. Es ist auch sinnvoll, im UI-Code etwas weniger streng zu sein oder mit Framework-Idiomen umzugehen, z. B. Verwendung von Standardexporten