@adidahiya Siehe diesen Kommentar von @nchen63.

Von @nchen63 :

Es behebt Tabs -> x Leerzeichen und x Leerzeichen -> Tabs, aber keine x Leerzeichen -> y Leerzeichen

Es SOLLTE jedoch x spaces bis y spaces tun.

Mein Projekt verwendet sowohl 2 als auch 4 Leerzeichen. Regel x spaces auf y spaces zu korrigieren wäre sehr nützlich.

Ich bin auch auf dieses Problem gestoßen, in der Erwartung, dass es Größenverletzungen behebt oder zumindest als Fehler meldet, damit ich sie beheben kann. Im Moment scheint die auf der Site (https://palantir.github.io/tslint/rules/indent/) dokumentierte Konfiguration für die Einzugsgröße nichts zu tun.

Ja, bitte beheben Sie diesen Fehler. Angular CLI verwendet beim Generieren einer Datei oder eines Projekts 2 Leerzeichen für eine Einrückungsebene, und alle Anführungszeichen sind einfache Anführungszeichen. Dann führt es tslint aus, um diese gemäß der tslint.json des Benutzers zu beheben. Anführungszeichen funktionieren gut (verwandeln sich nach meiner Vorliebe in doppelte Anführungszeichen), aber der Einzug bleibt bei 2 Leerzeichen (während ich 4 bevorzuge). Tslint meldet nur dann einen Fehler, wenn es ein tatsächliches TAB-Zeichen sieht, scheint aber vernünftig, dass es auch die Anzahl der Leerzeichen überprüfen sollte

Es scheint mir, dass die Implementierung, die in https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts verwendet wird, ziemlich naiv ist, und ich würde nicht erwarten, dass sie für x spaces -> y spaces funktioniert work

Nehmen wir zum Beispiel an, dass eine Einzugsbreite von 2 Leerzeichen gewählt wurde, und betrachten Sie diesen Code:

foo = {
    a: {
  b: {
    c: 'c'
  }
    },
    d: 'd'
}

Wie würde unsere aktuelle Implementierung wissen, dass dies überhaupt scheitert? Jede Folge von Leerzeichen übergibt die Regex / / . Selbst wenn wir nach Vielfachen von 2 Leerzeichen suchen, würde dies passieren. In ähnlicher Weise könnten in Einrückungsszenarien mit mehreren Ebenen 4 führende Leerzeichen ein Durchgangsszenario sein, während der Beginn einer einzelnen Einrückungsebene mit 4 Leerzeichen fehlschlagen sollte.

Ich denke, jede Lösung müsste den AST durchlaufen, ähnlich wie eslint tut (https://github.com/eslint/eslint/blob/master/lib/rules/indent.js). Die Kehrseite davon wäre, dass wir für tabs -> spaces oder spaces -> tabs einen leichten Leistungseinbruch hinnehmen würden. Wir könnten das umgehen, indem wir die Implementierung basierend auf den Einstellungen auswählen, aber ich gehe davon aus, dass die aktuelle Implementierung fehlschlägt, wenn eine Kombination aus Tabulatoren und Leerzeichen verwendet wird. In diesem Fall sollten wir nur die AST-basierte Lösung verwenden.

Ich denke, dass zumindest ein Teil der AST-Arbeit, die in der eslint-Implementierung geleistet wurde, direkt von der typescript-Bibliothek verarbeitet werden kann, daher sollte die Lösung nicht zu schwer zu schreiben sein.

Wie würde unsere aktuelle Implementierung wissen, dass dies überhaupt scheitert?

Es muss _technisch_ nicht. Die Regel align würde Sie daran hindern, solchen Code zu schreiben. Natürlich könnten wir auch die AST in der indent Regel durchlaufen. Mir ist nur wichtig, dass eine Kombination aus indent und align es mir ermöglicht, das zu erreichen, was ich in der Problembeschreibung geschrieben habe.

Die align-Regel würde Sie daran hindern, solchen Code zu schreiben.

Schön! Das habe ich beim Untersuchen des Quellcodes übersehen. Da werde ich auch mal einen Gipfel machen. TBH, ich mag die Idee, bestehende Regeln zu nutzen, um andere so naiv wie möglich zu halten.

Ich habe das gleiche Problem. Die folgende Regel fängt Tabulatoren ab, die anstelle von Leerzeichen verwendet werden, aber nicht eine falsche Anzahl von Leerzeichen. Ich kann 2 in jede andere Nummer ändern, und ich erhalte immer noch keine Fehler. Ich verwende tslint 5.5.0.

"indent": [true, "spaces", 2],

Irgendwelche Updates dazu? (Wenn jemand noch nicht an einem Fix arbeitet, bin ich bereit, es auszuprobieren.)

@mDibyo mach es

@mDibyo Hast du

Ich habe eine Teilimplementierung. Werde versuchen, es zu vervollständigen und über das Wochenende eine PR zu veröffentlichen

Ich wollte nur eine Vorwarnung geben, dass dieses Thema für mich eine geringere Priorität hat, seit ich begonnen habe, hübschere Formatierungen mit

Prettier hingegen ist bestrebt, den meisten Code in jede Zeile zu integrieren.

Was ist, wenn Sie das nicht wollen?

Wenn die Druckbreite auf 120 eingestellt ist, kann hübscher einen übermäßig kompakten oder anderweitig unerwünschten Code erzeugen.

Wir verwenden 120 Zeichen in unseren Projekten.

Außerdem ist es eine weitere Abhängigkeit. Ich denke, dass ich es vorziehen würde, nur normale TSLint-Regeln zu verwenden.

Ich denke, dass ich es vorziehen würde, nur normale TSLint-Regeln zu verwenden.

@glen-84 ja, das ist in Ordnung, weshalb ich nicht sage, dass wir alle Formatierungsregeln aus TSLint entfernen und vollständig an einen externen Formatierer delegieren sollten. Prettier ist offensichtlich eigensinnig und nicht jeder wird sich dafür entscheiden, es zu benutzen. Dieses Thema ist für PRs noch offen.

was ist mit diesem Problem los?

Meine PR ist in Arbeit, in vielen Fällen braucht es noch Zeit. @cyberhck

Wir erwarten also, dass es ziemlich bald zusammengeführt wird :slightly_smiling_face:

Irgendein Update hier?

Vielleicht könnten wir die Betreuer des Typoskript-Formatierers bitten, ein paar APIs bereitzustellen? Das Paket kann bereits überprüfen, ob eine gesamte Quelldatei gemäß den Einstellungen in einer tslint.json Datei formatiert ist

Es kann jedoch helfen, mit dem Fixer-Setup von TSLint gut zu spielen.

Das Problem scheint zu sein, dass ein Fehler nur gemeldet wird, wenn das falsche Leerzeichen verwendet wird, nicht wenn die Einzugsgröße deaktiviert ist.

@adidahiya Ich kann keinen Fehler melden, wenn das falsche

export function foo() {
return 123;
}

oder

export function foo() {
<tab>return 123;
}

Es meldet keinen Fehler zurück. Sind Sie gemäß Ihrem ursprünglichen Kommentar sicher, dass es gemeldet wird, wenn es sich um das falsche Leerzeichen handelt?

Irgendein Fortschritt dazu? Fragt nur

Beratung? Verwenden Sie Schöner .

Hat jemand tslint-eslint-Regeln ausprobiert ?

@jscharett tslint-eslint-rules arbeitet mit der Regel ter-indent . Leider deckt es die JSX-Einrückung nicht ab...

Gibt es hier Hoffnung auf Abhilfe?

Dieser Fehler ist in v5.10.0 immer noch nicht behoben

Ich muss sagen, ich kann mir nicht vorstellen, dass TSLint jemals in der Lage sein wird, JS-Code so gut zu formatieren wie Prettier. Dies ist ein kompliziertes Problem, und Prettier hat es besser als jeder andere gelöst. Ich denke nicht, dass wir uns dafür auf TSLint verlassen sollten, zumal Projekte oft beide Tools gleichzeitig verwenden und es wahrscheinlich zu Konflikten kommen wird...

BEARBEITEN: Um eine bessere Vorstellung davon zu bekommen, _wie_ kompliziert dieses Problem ist, lesen Sie diese PR oder werfen Sie einen Blick auf den Prettier-Quellcode. Wenn Ihnen diese Demonstrationen nicht "kompliziert" vorkommen, helfen Sie diesem Projekt bitte mit einer PR !

@aervin Ich bin hier eher anderer Meinung. Die 2 Projekte haben meiner Meinung nach unterschiedliche Zwecke. Prettier fällt in die Kategorie der Formatierung, während TSLint eher der Validierung entspricht. Ja, TSLint kann einige Regeln formatieren, aber sein beabsichtigter Zweck als Linter geht auf die Validierung zurück.

Das Problem, sich auf Prettier zu verlassen, ist, dass es rechthaberisch ist. Das ist großartig, wenn Sie mit seinem Stil einverstanden sind, aber was ist, wenn Sie dies nicht tun? Früher haben wir alle JSLint verwendet, und wir haben uns alle beschwert, weil es so eigensinnig war. Dann kamen JSHint und JSCS, die uns eine gewisse Kontrolle gaben. Jetzt haben wir leistungsstarke Tools wie @eslint, die uns die Möglichkeit geben, Plug-and-Play und Probleme automatisch zu "beheben".

Obwohl ich mir sicher bin, dass Prettier ein großartiges Projekt ist, sehe ich es persönlich als Rückschritt. Es nimmt mir die Kontrolle. TSLint muss den Code nicht "korrigieren", wenn dies das Problem ist, kennzeichnen Sie es einfach als Problem. Ich bezweifle nicht, dass dieses Problem kompliziert ist, aber eslint hat es gelöst. Die Regel hat funktioniert; Was hat sich geändert, um es zu brechen?

@jscharett Danke für deine sympathische Antwort. Ich stimme zu, dass diese Projekte unterschiedliche Zwecke haben oder haben sollten. Mein Argument ist, dass wir diese Projekte auf diese Zwecke beschränken sollten. Überlassen wir Prettier der Behebung von Einrückungsproblemen und überlassen wir TSLint der Warnung der Entwickler vor Pfeilfunktionen, die vereinfacht werden können.

Ich stimme auch zu, dass Prettier rechthaberisch ist. Das mag ich eher an Prettier. Jetzt muss mein Team nicht mehr darüber diskutieren, welche Meinung zur Formatierung vernünftiger ist. Über Prettier können wir uns alle beschweren :lacht: .

BEARBEITEN:

Die Regel hat funktioniert; Was hat sich geändert, um es zu brechen?

Der Kommentar zur Eröffnungsausgabe lässt mich glauben, dass diese Regel nie wie beabsichtigt funktioniert hat.

Obwohl ich mir sicher bin, dass Prettier ein großartiges Projekt ist, sehe ich es persönlich als Rückschritt. Es nimmt mir die Kontrolle.

Meine Erfahrung war, dass ich dachte, es wäre mir wichtig, die Formatierungsregeln genau zu kontrollieren, bis ich Prettier hinzufügte ... und bald darauf wurde mir klar, dass mir die besondere Art und Weise, wie die Dinge formatiert wurden, nicht so wichtig war, als die Tatsache, dass sie wurden einheitlich formatiert. Es ist eine enorme kognitive Belastung, sich darüber keine Gedanken mehr zu machen und sich ganz darauf zu konzentrieren, was der Code _tun_ soll, anstatt wie er aussieht.

tslint validiert bereits andere Dinge, die unter die Kategorie der Formatierung fallen würden. Zum Beispiel das Erzwingen von Ausrichtung, Klammerstil oder Leerzeichen zwischen Variablennamen und Operatoren. Darüber hinaus ist es wünschenswert, die Einrückung validieren zu können, ohne sich auf eine eigenwillige Lösung wie hübscher verlassen zu müssen.

Braucht weniger Diskussion und mehr PR. 😉😉

mach weiter

Mein Kommentar war meist augenzwinkernd. Obwohl ich mich frage, warum dieses Problem über ein Jahr alt ist und keine Fortschritte gemacht wurden. Es scheint, als würden sich alle nur über Linting vs Prettier streiten.

@ffxsam Weil es Debatten darüber gibt, ob es bei tslint mehr um den ts-Teil oder um den lint-Teil geht

Das ist ein gültiger Punkt. Anscheinend gibt es einige Überschneidungen mit TSLint/ESLint. Aber die Tatsache bleibt, dass es eine nicht funktionierende Option indent , die seit wer weiß wie lange kaputt ist. Es scheint, als ob jemand, der mit der TSLint-Codebasis vertraut ist, das Problem am schnellsten / einfachsten beheben könnte ...?

Stimmen Sie ab, um x spaces => y spaces zu reparieren. Dies ist eine Funktion, auf die unser Unternehmen sehr angewiesen ist. Es macht keinen Sinn, das einfach nicht zu reparieren.

@ffxsam Ich beobachte diese Ausgabe jetzt seit fast einem Jahr, ja, es ist lange her, aber wie Sie sehen, gibt es zwei PR-Versuche, und es hat bis jetzt nicht geklappt, ich denke, es ist schwieriger als es aussieht, aber von Für Betreuer ist es natürlich einfacher, ich habe nur viel Geduld :slightly_smiling_face:

Im leeren Projekt noch reproduzierbar
https://github.com/dimaShin/tslint-reproduce-2814

Hallo @dimaShin ,

Wir warten nur auf diese Funktion, möglicherweise mit Fixoption, aber das ist für mich kein Problem. Als ich das letzte Mal überprüft habe, dass die Leute hübscher verwendet haben, um nach Einrückungen zu suchen, und Tslint für alles andere.

Ich sage nicht, dass das gut zu Ihnen passt, für mich ist es das sicherlich nicht. Ich würde auch vorschlagen, .editorconfig für diese spezielle Option zu verwenden und später zu Tslint zu wechseln, wenn dies gelöst ist.

Nochmals vielen Dank, dass Sie sich die Zeit genommen haben, weitere Informationen hinzuzufügen :)

Lassen Sie uns eine Strategie für die Überprüfung der Einrückung festlegen. Als Referenz hier die Strategie, die von eslint verwendet wird:

1. Eine OffsetStorage-Instanz speichert eine Zuordnung der gewünschten Offsets, wobei jedes Token einen angegebenen Offset von einem anderen angegebenen Token oder zur ersten Spalte hat.
2. Modifizieren Sie beim Durchlaufen des AST die gewünschten Token-Offsets entsprechend. Wenn Sie beispielsweise ein BlockStatement eingeben, versetzen Sie alle Token im BlockStatement um 1 Einzugsebene von der öffnenden geschweiften Klammer des BlockStatements.
3. Berechnen Sie nach dem Durchlaufen des AST die erwarteten Einrückungsebenen jedes Tokens gemäß dem OffsetStorage-Container.
4. Vergleichen Sie für jede Zeile die erwartete Einrückung des ersten Tokens mit der tatsächlichen Einrückung in der Datei, und melden Sie das Token, wenn die beiden Werte nicht gleich sind.

Diese Strategie basiert auf der Syntax, die nach früheren Kommentaren zu eigensinnig ist, weil sie einen bestimmten Zeilenumbruch erfordert. Ich schlage eine einfache Möglichkeit vor, die Einrückung zu überprüfen, die unabhängig davon ist, wie der Code in Zeilen unterteilt ist:

1. Die Einzugseinheit wird in den Einstellungen definiert. Bei Tabulatoren ist es ein Tabulatorzeichen. Bei Leerzeichen sind es zwei oder vier Leerzeichen.
2. Die erste nicht leere Zeile der Datei sollte null Einrückungseinheiten haben
3. Jede nachfolgende nicht-leere Zeile sollte entweder
   A. Die gleiche Anzahl von Einrückungseinheiten wie die vorangehende nicht leere Zeile oder
   B. Weniger als die Anzahl der Einrückungseinheiten als die vorangehende nicht leere Zeile oder
   C. Genau eine mehr als die Anzahl der Einrückungseinheiten als die vorangehende nicht leere Zeile

Einige zusätzliche Dinge zu besprechen:

• Der Größenparameter hat bei Tabs keine Auswirkung (warum?)
• Es gibt keinen Grund, warum der Größenparameter keine positive ganze Zahl sein kann
• Die automatische Korrektur der Einrückungsgröße kann wahrscheinlich nicht implementiert werden, ohne den Weg der Syntaxstrategie zu gehen

@stifflerus Regel sollte auch mit if/for/arrow-Funktion ohne {}

@maximelkin Sind die von Ihnen angegebenen Beispiele in der zweiten Zeile nicht eingerückt? Können Sie ein Beispiel dafür nennen, wo die vorgeschlagene Strategie scheitern würde?

if(this) that(); //okay because it's all one line

if(this)
  that(); //also okay because the second line is indented

let x = () => f(); //okay because it's all one line

let y = () =>
  f(); // I have not seen any code but like this but it would be okay

Wäre super wenn das behoben wäre.

Ich kann nicht glauben, dass etwas so grundlegendes wie die Durchsetzung von Einrückungsregeln immer noch nicht funktioniert.

Es gibt also keine Möglichkeit, einen solchen ts-Code im Jahr 2018 zu fluten?

const x = {
  a: 1,
   b: 2,
}

Funktioniert bei mir
./.eslintrc.ts.js :

module.exports = {
  'parser': 'typescript-eslint-parser',
  'parserOptions': {
    'ecmaVersion': 6,
    'sourceType': 'module',
    'ecmaFeatures': {
      'jsx': true,
    }
  },
  'plugins': [
    'react',
  ],
  'rules': {
    'indent': ['error', 2],
  },
}

yarn eslint --no-eslintrc --config ./.eslintrc.ts.js --ext .tsx src

https://github.com/eslint/typescript-eslint-parser

Die Lösung, die ich für das Einrückungsproblem in Angular gefunden habe, besteht darin, mit den nächsten Schritten hübscher hinzuzufügen:
npm install --save-dev tslint-plugin-prettier prettier tslint-jasmine-rules
tslint.json bearbeiten -->
` "Regelverzeichnis": [
"node_modules/codelyzer",
"node_modules/tslint-plugin-prettier",
"node_modules/tslint-jasmin-rules/dist"

],
"erweitert": "tslint-plugin-prettier",

"Regeln": {
"schöner": wahr,
//Füge hier deine gewünschten Regeln hinzu`

und in packagege.json hinzufügen -->
" ,"schöner": {
"singleQuote": wahr,
"printWidth": 140,
"halb": wahr,
"bracketSpacing": wahr,
"arrowParens": "immer",
"parser": "typescript"
}"

Dies ist eine Funktionalität, die fast jeder täglich nutzt. Wäre dankbar, wenn dieses Thema mehr Aufmerksamkeit bekommt.

Leute, Sie können die Option ter- indent verwenden, die von tslint-eslint-rules bereitgestellt wird.

"ter-indent": [ true, 4, { "SwitchCase": 1 }]

Bei mir hat es funktioniert. Beifall!

@hiteshaleriya das habe ich seit behebt die Fehler nicht wirklich, sondern tslint.json :

{
    "extends": "tslint-config-airbnb",
    "rules": {
        "ter-indent": ["error", "spaces", 4],
        "no-unused-vars": ["warn"],
        "no-multi-spaces": false,
        "no-console": false,
        "max-line-length": false,
        "import-name": false
    }
}

und hier ist ein relevantes Beispiel, das ohne Warnungen oder Fehler beendet wurde:

function retrieveAndSetConfig(): Promise<any> {
  return new Promise((resolve, _) => {
  // ^ 2 spaces, expected 4
    const ghe = new GHEUtils();
    // ^ 4 spaces, expected 8
    // ...
}

Es werden auch keine Fehler angezeigt, wenn Tabulatoren verwendet werden (obwohl dies beabsichtigt sein könnte, wenn 4 Leerzeichen vorhanden sind?).

@SpencerKaiser Können Sie bitte Ihre ter-indent-Regel wie unten gezeigt aktualisieren und dann versuchen:

"ter-indent": [true, 4]

Ich habe Ihr Beispiel ausprobiert und es funktioniert wie erwartet an meinem Ende (verursacht Fehler).

@hiteshaleriya danke, dass du mir so schnell --fix . Irgendwelche Ideen?

@SpencerKaiser Können Sie versuchen, den Befehl --fix zweimal auszuführen. Beim ersten Mal wird nur die erste Zeile eingerückt, beim zweiten Mal wird der Rest eingerückt (für Ihren Beispielcode). Scheint seltsam, aber bitte melden Sie das Problem, wenn es nicht funktioniert.

@hiteshaleriya, also ein paar Beobachtungen ... Ich musste es nicht noch einmal ausführen, ich musste es ungefähr n/4 mal ausführen, wobei n die Länge der Einrückung in Leerzeichen des ist am weitesten eingerückte Zeile im Projekt ¯\_(ツ)_/¯

Nachdem sie alle endlich fertig sind, scheint es, dass grundlegende Einrückungsfehler wie diese übersprungen werden:

class Something {
    function myFunc() {
        const myThing = {
            wat: 1,
         wattt: 5,    // 9 spaces, expected 12
        };
    }
}

Wenn ich die Einrückungsebene von const (Zeile 17) auf 0 Leerzeichen durcheinander bringe, wird der Rest mit Fehlern markiert _ausschließen_ der Zeile mit dem Leerzeichen, wenn ich --fix weglasse:

ERROR: 17:1  ter-indent  Expected indentation of 8 spaces but found 0.
ERROR: 18:1  ter-indent  Expected indentation of 4 spaces but found 12.
ERROR: 20:1  ter-indent  Expected indentation of 0 spaces but found 8.

Mit --fix ist hier der erste Durchgang:

        const myThing = {
    wat: 1,
         wattt: 5,
};

Und der zweite Durchgang:

        const myThing = {
            wat: 1,
         wattt: 5,
        };

Gedanken??

Wie ich dieses Problem mit tslint-config-prettier gelöst habe

@shubich Ich habe das gleiche gemacht ...

Gibt es dazu ein Update?

@MaKCbIMKo soweit ich das verstanden habe, wird das gesamte Team eslint besuchen typescript-eslint integrieren, und in naher Zukunft wird tslint veraltet sein, also ist es so gut wie diese Regel vorerst zu ignorieren (oder verwenden Sie die tslint-config-prettier )

Abschluss aufgrund der Komplexität dieser Aufgabe und der Änderung der Projektrichtung: #4534

Die ESLint-Regel von typescript-eslint funktioniert bei mir perfekt (siehe #4534):

module.exports = {
    "env": {
        "browser": true,
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2019,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        },
        "project": "./tsconfig.json",
    },
    "plugins": ["@typescript-eslint"],
    "rules": {
        "@typescript-eslint/indent": ["error", 2] // or ["error", "tab"]
    }
}

Wie ich dieses Problem mit tslint-config-prettier gelöst habe

Link nicht gefunden.

🤖 Beep boop! 👉 TSLint ist veraltet 👈 und Sie sollten zu typescript-eslint wechseln ! 🤖

🔒 Dieses Problem wird gesperrt, um weitere unnötige Diskussionen zu vermeiden. Danke! 👋

PS tslint-config-prettier - bitte hören Sie auf, _linters_ wie TSLint zu verwenden, um Ihr TypeScript zu _formatieren_. Das macht besser ein _formatter_ wie Prettier .