Tslint: Watch-Option hinzufügen

Ich möchte dieses Problem ansprechen, da es seit dem 24. August keine Aktivität gab, und ich denke, das ist wichtig.

Ich verwende nodemon zum Überwachen von Dateiänderungen und führe tslint im npm-Skript aus. Ein Beispiel https://github.com/ryancat/create-ts-library/blob/master/package.json#L9

Sie müssen nicht mit Fehlercode 2 beenden, um zu verhindern, dass nodemon beendet wird.

Ich möchte nur die Notwendigkeit dieser Funktion betonen.

Ich möchte, dass diese Funktion implementiert wird

Ich habe Fieber. Und das einzige Rezept ist mehr --watch .

Dies ist eine _sehr schwierige_ Funktion, die implementiert werden muss, da sie wahrscheinlich eine radikale Neugestaltung der Architektur erfordert, um inkrementelle Wiederholungen zu unterstützen. Daher denke ich, dass die beste Wahl hier darin besteht, tslint mit anderen vorhandenen Watcher-Tools zu kombinieren, wie z. B. nodemon , die oben erwähnt wurden, oder https: //www.npmjs.com/package/watch

erfordert eine radikale Neugestaltung der Architektur, um inkrementelle Wiederholungen zu unterstützen

FWIW, das klingt sehr hart, aber auch performanter als das erneute Ausführen von tslint bei Änderungen, wie dies bei Tools von Drittanbietern der Fall wäre. +1 zu dieser Anfrage, zusammen mit einer gesunden Seite des Verständnisses.

⌚ing dies.

Mein Tool unterstützt dieses Verhalten tatsächlich, weil ich verstehe, dass es wirklich schwer zu implementieren ist. https://github.com/guidojo/multipleTypescriptCompilers#readme

Das Tool führt derzeit einen TSC-Compiler aus und lintet nach jedem Lauf jede Datei einzeln. Wenn sie durch eine andere Kompilierung unterbrochen wird, wird sie abgebrochen. :)

Hat sich das schon jemand angeschaut?

In der Zwischenzeit verwende ich das Paket onchange in meinen npm-Skripten: https://github.com/alexburner/chain-of-being/blob/85230a5b0bf06e1e0a729559c340493c93dac008/package.json#L18

Nachdem Sie es in den prettier -Dokumenten gesehen haben: https://prettier.io/docs/en/watching-files.html

Die Verwendung des Pakets onchange funktioniert perfekt, vielen Dank für diesen Vorschlag @alexburner. Verwenden Sie es derzeit sowohl für tslint als auch für stylelint:

{
    "lint": "concurrently \"yarn tslint:once\" \"yarn stylelint:once\" && onchange 'src/**/*.*' -- concurrently \"yarn tslint:once\" \"yarn stylelint:once\"",
    "tslint:once": "tslint -p . -c ./tslint.json --fix './src/**/*.+(ts|tsx)'",
    "stylelint:once": "stylelint --fix **/*.scss",
}

Ich denke, die onchange -Lösung ist für CLI-Anwendungsfälle ausreichend. Sie können die Node-API verwenden und darüber hinaus einen Watcher implementieren, wenn Sie möchten. Ich werde dies schließen, weil wir die Entwicklungsbemühungen auf andere Bereiche in TSLint konzentrieren möchten.

Ich bin nicht der Meinung, dass dies geschlossen werden sollte und zumindest auf der Roadmap bleiben sollte, auch wenn der Fokus derzeit woanders liegt. Das Beobachten erscheint im Vergleich zu tsc -w von tsc übermäßig kompliziert