@adidahiya Voir ce commentaire de @nchen63.

De @nchen63 :

Il corrige les onglets -> x espaces et x espaces -> onglets, mais ne corrige pas x espaces -> y espaces

Il DEVRAIT faire x spaces à y spaces cependant.

Mon projet utilise à la fois 2 et 4 espaces. Corriger la règle x spaces à y spaces serait très utile.

J'ai également rencontré ce problème en m'attendant à ce qu'il corrige les violations de taille, ou au moins les signale comme des erreurs afin que je puisse les corriger. Pour le moment, il semble que la configuration de la taille de retrait documentée sur le site (https://palantir.github.io/tslint/rules/indent/) ne fasse rien.

Oui, veuillez corriger ce bug. Angular CLI utilise 2 espaces pour un niveau d'indentation lors de la génération d'un fichier ou d'un projet, et tous les guillemets sont des guillemets simples. Ensuite, il exécute tslint pour les corriger en fonction du tslint.json de l'utilisateur. Les guillemets fonctionnent bien (se transformant en guillemets doubles selon ma préférence), mais l'indentation reste à 2 espaces (alors que je préfère 4). Tslint ne signale une erreur que s'il voit un caractère TAB réel, mais semble raisonnable qu'il doive également vérifier le nombre d'espaces

Il me semble que l'implémentation utilisée dans https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts est assez naïve, et je ne m'attendrais pas à ce que cela fonctionne pour x spaces -> y spaces . L'approche semble convenir aux onglets, d'après le commentaire ici, mais je ne vois pas cette approche comme viable pour les espaces.

Disons, par exemple, qu'une largeur d'indentation de 2 espaces a été choisie, et considérons ce code :

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

Comment notre mise en œuvre actuelle pourrait-elle échouer du tout ? Chaque séquence d'espaces passe la regex / / . Même si nous cherchions des multiples de 2 espaces, cela passerait. De même, dans les scénarios d'indentation à plusieurs niveaux, 4 espaces de début pourraient être un scénario de réussite, tandis que le démarrage d'un seul niveau d'indentation avec 4 espaces devrait échouer.

Je pense que toute solution devrait traverser l'AST, comme le fait eslint (https://github.com/eslint/eslint/blob/master/lib/rules/indent.js). L'inconvénient serait que nous prenions un léger coup de performance pour tabs -> spaces ou spaces -> tabs . Nous pourrions contourner ce problème en choisissant l'implémentation en fonction des paramètres, mais je prévois que l'implémentation actuelle échouera si une combinaison d'onglets et d'espaces est utilisée, auquel cas nous ne devrions utiliser que la solution basée sur AST.

Je pense qu'au moins une partie du travail AST effectué dans l'implémentation eslint peut être gérée directement par la bibliothèque de typescript, donc la solution ne devrait pas être trop difficile à rédiger.

Comment notre mise en œuvre actuelle pourrait-elle échouer du tout ?

Ce n'est pas _techniquement_ nécessaire. La règle align vous empêcherait d'écrire du code comme ça. Bien sûr, nous pourrions également parcourir l'AST dans la règle indent . Tout ce qui m'importe, c'est qu'une combinaison de indent et align me permette d'accomplir ce que j'ai écrit dans la description du problème.

La règle d'alignement vous empêcherait d'écrire du code comme ça.

Agréable! J'ai raté cela lorsque j'examinais le code source. Je vais faire un pic là-bas aussi. TBH, j'aime bien l'idée de tirer parti des règles existantes pour garder les autres aussi naïfs que possible.

Je rencontre le même problème. La règle ci-dessous attrapera les tabulations utilisées au lieu des espaces, mais n'attrapera pas un nombre incorrect d'espaces. Je peux changer 2 en n'importe quel autre nombre, et je n'obtiens toujours aucune erreur. J'utilise tslint 5.5.0.

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

Des mises à jour à ce sujet ? (Si quelqu'un ne travaille pas déjà sur un correctif, je suis prêt à essayer.)

@mDibyo vas-y

@mDibyo Avez-vous fait des progrès à ce sujet ?

J'ai une implémentation partielle. J'essaierai de le terminer et de mettre en place un PR au cours du week-end

Je voulais juste signaler que ce problème est devenu une priorité moindre pour moi depuis que j'ai commencé à utiliser un formatage plus joli avec

Prettier, d'autre part, s'efforce d'insérer le plus de code dans chaque ligne.

Et si tu ne veux pas ça ?

Avec la largeur d'impression définie sur 120, plus joli peut produire un code trop compact ou autrement indésirable.

Nous utilisons 120 caractères dans nos projets.

C'est aussi une autre dépendance. Je pense que je préférerais simplement utiliser les règles TSLint standard.

Je pense que je préférerais simplement utiliser les règles TSLint standard.

@glen-84 ouais, ça va, c'est pourquoi je ne dis pas que nous devrions supprimer toutes les règles de formatage de TSLint et déléguer complètement à un formateur externe. Prettier est évidemment opiniâtre et tout le monde ne choisira pas de l'utiliser. Cette question est toujours ouverte pour les PR.

que se passe-t-il avec ce problème ?

mon pr travaille en cours, dans de nombreux cas, a encore besoin de temps. @cyberhck

nous nous attendons donc à ce qu'il soit fusionné assez rapidement alors :slightly_smiliing_face:

Une mise à jour ici ?

Peut-être pourrions-nous demander aux responsables dactylographiés d'exposer quelques API ? Le package peut déjà vérifier qu'un fichier source entier est formaté

Cependant, il peut avoir besoin d'aide pour bien jouer avec la configuration du fixateur de TSLint.

Le problème semble être qu'un échec n'est signalé que si vous utilisez le mauvais caractère d'espacement, pas si la taille de l'indentation est désactivée.

@adidahiya Je ne parviens pas à lui faire rapporter une erreur si le mauvais caractère d'indentation est utilisé. Si je définis la règle sur des espaces/4 et que j'ai quelque chose comme :

export function foo() {
return 123;
}

ou alors

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

Il ne rapporte pas d'erreur. D'après votre commentaire d'origine, êtes-vous sûr qu'il le signale s'il s'agit du mauvais caractère d'espacement ?

Une avance là-dessus ? Je demande juste

Conseils? Utilisez plus joli .

Quelqu'un a-t-il essayé tslint-eslint-rules ?

@jscharett tslint-eslint-rules fonctionne avec la règle ter-indent . Malheureusement, cela ne couvre pas l'indentation JSX...

Un espoir d'un correctif ici?

Ce bug n'est toujours pas corrigé dans la v5.10.0

Je dois dire que je n'imagine pas que TSLint sera un jour capable de formater du code JS aussi bien que Prettier. C'est un problème compliqué, et Prettier l'a résolu mieux que quiconque. Je ne pense pas que nous devrions nous fier à TSLint pour cela, d'autant plus que les projets utilisent souvent les deux outils en tandem, et des conflits surgiront probablement...

EDIT : pour une meilleure idée de la complexité de ce problème, consultez ce PR ou jetez un œil au code source de Prettier. Si ces démonstrations ne vous paraissent pas "compliquées", aidez ce projet avec un PR 😄 !

@aervin J'ai tendance à être en désaccord ici. Les 2 projets, à mon avis, ont des objectifs différents. Prettier tombe dans la catégorie du formatage tandis que TSLint est plus en phase avec la validation. Oui, TSLint peut effectuer le formatage de certaines règles, mais son objectif en tant que linter revient à la validation.

Le problème de se fier à Prettier, c'est qu'il est opiniâtre. C'est bien si vous êtes d'accord avec son style, mais que faire si vous ne l'êtes pas ? Nous utilisions tous JSLint, et nous nous sommes tous plaints parce qu'il était tellement opiniâtre. Puis sont venus JSHint et JSCS, qui nous ont donné un certain contrôle. Maintenant, nous avons des outils puissants comme @eslint qui nous ont donné la possibilité de plug-n-play et de "réparer" les problèmes automatiquement.

Même si je suis sûr que Prettier est un grand projet, je le vois personnellement comme un pas en arrière. Ça me prend le contrôle. TSLint n'a pas besoin de "réparer" le code, si tel est le problème, signalez-le simplement comme un problème. Je ne doute pas que ce problème soit compliqué, mais eslint l'a résolu. La règle fonctionnait; qu'est-ce qui a changé pour le casser ?

@jscharett Merci pour votre réponse sympathique. Je conviens que ces projets ont des objectifs différents, ou _devraient_ avoir. Mon argument est que nous devrions limiter ces projets à ces fins. Laissons Prettier résoudre les problèmes d'indentation et laissons TSLint avertir les développeurs des fonctions de flèche qui peuvent être simplifiées.

Je suis également d'accord que Prettier est opiniâtre. J'aime plutôt ça à propos de Prettier. Désormais, mon équipe n'a plus à discuter de l'opinion de formatage la plus raisonnable. On peut tous se plaindre de Prettier :rire: .

ÉDITER:

La règle fonctionnait; qu'est-ce qui a changé pour le casser ?

Le commentaire d'ouverture du problème me porte à croire que cette règle n'a jamais fonctionné comme prévu.

Même si je suis sûr que Prettier est un grand projet, je le vois personnellement comme un pas en arrière. Ça me prend le contrôle.

Mon expérience était que je pensais que je me souciais d'avoir un contrôle fin sur les règles de formatage jusqu'à ce que j'ajoute Prettier... et peu de temps après j'ai réalisé que je ne me souciais pas tant de la façon dont les choses étaient formatées, que du fait que ils ont été formatés de manière cohérente. C'est une énorme charge cognitive de ne plus s'inquiéter à ce sujet et de me concentrer entièrement sur ce que je veux que le code fasse plutôt que sur son apparence.

tslint valide déjà d'autres choses qui entreraient dans la catégorie du formatage. Par exemple, appliquer l'alignement, le style de crochet ou les espaces entre les noms de variables et les opérateurs. De plus, il est souhaitable de pouvoir valider l'indentation sans avoir à s'appuyer sur une solution avisée comme plus jolie.

Nécessite moins de discussions et plus de relations publiques. 😉😉

vas-y @ffxsam

Mon commentaire était surtout ironique. Bien que je me demande pourquoi ce problème date de plus d'un an et qu'aucun progrès n'a été réalisé. On dirait que tout le monde se dispute à propos de linting contre Prettier.

@ffxsam Parce qu'il y a un débat pour savoir si tslint concerne davantage la partie ts ou la partie peluche

C'est un argument valable. On dirait qu'il y a un certain chevauchement avec TSLint/ESLint. Mais le fait demeure qu'il y a une option indent qui ne fonctionne pas qui a été cassée depuis qui sait combien de temps. On dirait que la chose la plus rapide/la plus simple serait que quelqu'un connaissant la base de code TSLint le corrige...?

Votez pour la correction de x spaces => y spaces . C'est une caractéristique sur laquelle notre entreprise s'appuie fortement. Cela n'a aucun sens de ne pas régler cela.

@ffxsam Je regarde ce problème depuis presque un an maintenant, oui ça fait longtemps, mais comme vous pouvez le voir, il y a deux tentatives de relations publiques, et cela n'a pas fonctionné jusqu'à présent, je pense que c'est plus difficile qu'il n'y paraît, mais de bien sûr pour les responsables cela pourrait être plus facile, j'ai juste beaucoup de patience :slightly_smiliing_face:

Toujours reproductible dans le projet vide
https://github.com/dimaShin/tslint-reproduce-2814

Salut @dimaShin , merci d'avoir pris le temps de créer un référentiel reproductible. Cependant, l'équipe est déjà au courant de ce problème, la reproduction n'a jamais été un problème.

Nous attendons simplement cette fonctionnalité, éventuellement avec une option de correction, mais ce n'est pas un problème pour moi. La dernière fois que j'ai vérifié, les gens utilisaient plus joli pour vérifier l'indentation et tslint pour tout le reste.

Je ne dis pas que cela vous conviendra, ce n'est certainement pas le cas pour moi, je suggérerais également d'utiliser .editorconfig pour cette option particulière et de passer à tslint plus tard lorsque cela sera résolu.

Encore une fois, merci d'avoir pris le temps d'ajouter plus d'informations :)

Déterminons une stratégie pour vérifier l'indentation. Pour référence, voici la stratégie utilisée par eslint :

1. Une instance OffsetStorage stocke une carte des décalages souhaités, où chaque jeton a un décalage spécifié par rapport à un autre jeton spécifié ou à la première colonne.
2. Au fur et à mesure que l'AST est parcouru, modifiez les décalages de jetons souhaités en conséquence. Par exemple, lors de la saisie d'un BlockStatement, décalez tous les jetons du BlockStatement d'un niveau de retrait par rapport à l'accolade ouvrante du BlockStatement.
3. Après avoir traversé l'AST, calculez les niveaux d'indentation attendus de chaque jeton en fonction du conteneur OffsetStorage.
4. Pour chaque ligne, comparez l'indentation attendue du premier jeton à l'indentation réelle dans le fichier et signalez le jeton si les deux valeurs ne sont pas égales.

Cette stratégie est basée sur la syntaxe, qui, sur la base des commentaires précédents, est trop opiniâtre car elle nécessite de rompre les lignes d'une certaine manière. Je propose un moyen simple de vérifier l'indentation qui est indépendant de la façon dont le code est divisé en lignes :

1. L'unité d'indentation est définie dans les paramètres. Pour les tabulations, il s'agit d'un caractère de tabulation. Pour les espaces, il s'agit de deux ou quatre caractères d'espacement.
2. La première ligne non vide du fichier doit avoir zéro unité d'indentation
3. Chaque ligne non vide suivante doit avoir soit
   une. Le même nombre d'unités d'indentation que la ligne non vide précédente ou
   b. Inférieur au nombre d'unités d'indentation de la ligne non vide précédente ou
   c. Exactement une de plus que le nombre d'unités d'indentation que la ligne précédente non vide

Quelques points supplémentaires à discuter :

• Le paramètre size n'a aucun effet avec les onglets (pourquoi ?)
• Il n'y a aucune raison pour que le paramètre de taille ne puisse pas être un entier positif
• La correction automatique de la taille de l'indentation ne peut probablement pas être implémentée sans suivre la voie de la stratégie de syntaxe

@stifflerus La règle devrait également fonctionner avec la fonction if/for/arrow sans {} blocs

@maximelkin Les exemples que vous avez donnés ne sont-ils pas en retrait sur la deuxième ligne? Pouvez-vous donner un exemple où la stratégie proposée échouerait ?

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

Ce serait génial si cela était corrigé.

Je ne peux pas croire que quelque chose d'aussi fondamental que l'application des règles d'indentation ne fonctionne toujours pas.

Donc, il n'y a aucun moyen de pelucher un tel code ts en 2018 ?

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

Travaille pour moi
./.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

la solution que j'ai trouvée pour le problème d'indentation dans angulaire est d'ajouter plus joli avec les prochaines étapes :
npm install --save-dev tslint-plugin-prettier joli tslint-jasmine-rules
modifier tslint.json -->
` "répertoire règles": [
"node_modules/codelyzer",
"node_modules/tslint-plugin-joli",
"node_modules/tslint-jasmine-rules/dist"

],
"extends": "tslint-plugin-joli",

"des règles": {
"plus joli": vrai,
//ajoutez ici vos règles souhaitées`

et dans packege.json ajouter -->
" ,"plus jolie": {
"singleQuote": vrai,
"printWidth": 140,
"semi": vrai,
"bracketSpacing": vrai,
"arrowParens": "toujours",
"parser": "dactylographié"
}"

Il s'agit d'une fonctionnalité que presque tout le monde utilise quotidiennement. J'apprécierais que ce problème reçoive plus d'attention.

Les gars, vous pouvez utiliser l'option ter- indent fournie par tslint-eslint-rules.

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

Cela a fonctionné pour moi. Acclamations!

@hiteshaleriya c'est ce que j'ai dans mon projet depuis un moment maintenant, mais cela ne 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
    }
}

et voici un exemple pertinent qui s'est terminé sans provoquer d'avertissements ou d'erreurs :

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

Il n'affiche pas non plus les erreurs lorsque les onglets sont utilisés (bien que cela puisse être par conception lorsque 4 espaces sont présents ?).

@SpencerKaiser Pouvez-vous mettre à jour votre règle de ter-indent comme indiqué ci-dessous, puis essayez :

"ter-indent": [true, 4]

J'ai essayé votre exemple et cela fonctionne comme prévu de mon côté (provoquant des erreurs).

@hiteshaleriya merci de me --fix . Des idées?

@SpencerKaiser Pouvez-vous essayer d'exécuter la commande --fix deux fois. La première fois, il indentera la première ligne seulement, puis la deuxième fois, il indentera le reste (pour votre exemple de code). Cela semble étrange, mais veuillez signaler le problème si cela ne fonctionne pas.

@hiteshaleriya donc quelques observations... Je n'ai pas eu besoin de l'exécuter à nouveau, j'avais besoin de l'exécuter environ n/4 fois où n est la longueur de l'indentation dans les espaces du ligne en retrait la plus éloignée du projet ¯\_(ツ)_/¯

Après les avoir tous finis, il semble qu'il saute les erreurs d'indentation de base comme celle-ci :

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

Si je gâche le niveau d'indentation des const (ligne 17) à 0 espaces, le reste est signalé avec des erreurs _excluant_ la ligne avec l'espace lorsque je laisse --fix :

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.

Avec --fix , voici la première passe :

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

Et la deuxième passe :

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

Les pensées??

Comment j'ai résolu ce problème avec tslint-config-prettier

@shubich j'ai fini par faire la même chose...

Y a-t-il une mise à jour à ce sujet?

@MaKCbIMKo pour autant que je

Fermeture en raison de la complexité de cette tâche et du changement de direction du projet : #4534

La règle ESLint de typescript-eslint fonctionne parfaitement pour moi (voir # 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"]
    }
}

Comment j'ai résolu ce problème avec tslint-config-prettier

Lien non trouvé.

Bip boop ! 👉 TSLint est obsolète 👈 et vous devriez passer à typescript-eslint ! 🤖

🔒 Ce problème est verrouillé pour éviter d'autres discussions inutiles. Merci! 👋

PS tslint-config-prettier - veuillez cesser d'utiliser des _linters_ tels que TSLint pour _formater_ votre TypeScript. C'est mieux fait par un _formateur_ tel que Prettier .