Tslint: Ajouter une option de surveillance

Créé le 23 août 2017  ·  14Commentaires  ·  Source: palantir/tslint

Je n'ai pas trouvé de problème avec une telle demande, donc j'en crée un

Declined Feature Request

Commentaire le plus utile

Je ne suis pas d'accord pour dire que cela devrait être fermé et devrait au moins rester sur la feuille de route même si l'accent est actuellement mis ailleurs. Regarder semble trop compliqué par rapport aux tsc -w de tsc

Tous les 14 commentaires

Je veux remonter ce problème car il n'y a eu aucune activité depuis le 24 août et je pense que c'est important.

J'utilise nodemon pour surveiller les modifications de fichiers et exécuter tslint dans le script npm. Un exemple https://github.com/ryancat/create-ts-library/blob/master/package.json#L9

Vous devrez ne pas quitter avec le code d'erreur 2 pour éviter que nodemon ne se ferme.

Je veux juste souligner la nécessité de cette fonctionnalité.

Je souhaite que cette fonctionnalité soit implémentée

J'ai de la fièvre. Et le seul prescript est plus --watch .

c'est une fonctionnalité _très difficile_ à mettre en œuvre car elle nécessite probablement une réarchitecture radicale pour prendre en charge les réexécutions incrémentielles, donc je pense que le meilleur pari ici sera de combiner tslint avec d'autres outils d'observation existants, comme nodemon mentionné ci-dessus ou https : //www.npmjs.com/package/watch

nécessite une réarchitecture radicale pour prendre en charge les réexécutions incrémentielles

FWIW qui semble très difficile, mais aussi plus performant que de réexécuter tout tslint lors d'un changement, comme cela se produirait avec des outils tiers. +1 à cette demande, avec un côté sain de compréhension.

⌚ing ceci.

Mon outil prend en charge ce comportement, car je comprends que c'est vraiment difficile à mettre en œuvre. https://github.com/guidojo/multipleTypescriptCompilers#readme

L'outil exécute actuellement un compilateur tsc et après chaque exécution, il peluchera chaque fichier séparément. S'il est interrompu par une autre compilation, il s'arrêtera. :)

Est-ce que quelqu'un s'est déjà penché là-dessus ?

En attendant, j'ai utilisé le package onchange dans mes scripts npm : https://github.com/alexburner/chain-of-being/blob/85230a5b0bf06e1e0a729559c340493c93dac008/package.json#L18

Après l'avoir vu dans la documentation prettier : https://prettier.io/docs/en/watching-files.html

L'utilisation du package onchange fonctionne parfaitement, merci beaucoup pour cette suggestion @alexburner. Je l'utilise actuellement pour tslint et 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",
}

Je pense que la solution onchange est suffisante pour les cas d'utilisation de la CLI. Vous pouvez utiliser l'API Node et implémenter un observateur en plus si vous le souhaitez. Je vais fermer ceci parce que nous aimerions concentrer nos efforts de développement ailleurs dans TSLint.

Je ne suis pas d'accord pour dire que cela devrait être fermé et devrait au moins rester sur la feuille de route même si l'accent est actuellement mis ailleurs. Regarder semble trop compliqué par rapport aux tsc -w de tsc

Cette page vous a été utile?
0 / 5 - 0 notes