Jshint: Le concept de « Trop d'erreurs » doit être supprimé

Créé le 2 juin 2011 · 11Commentaires · Source: jshint/jshint

Lorsqu'il existe encore des éléments controversés tels que les avertissements "onglets et espaces mixtes" qui ne peuvent pas être désactivés dans JSHint, la limite d'erreurs (c'est-à-dire "Trop d'erreurs") doit être supprimée afin que le fichier puisse être entièrement traité.

Je me fiche des avertissements "onglets et espaces mixtes" - je me soucie des choses qui vont casser mon code. Par conséquent, même si tout le monde dans le monde n'est pas d'accord et aime tellement ces avertissements qu'ils doivent être obligatoires dans JSHint, je devrais au moins avoir la possibilité d'exécuter tout mon fichier même si je suis obligé de passer au crible ces erreurs.

Source

derekdata

👍4

Commentaire le plus utile

maxerror doit être opt-in plutôt que opt-out. C'est vraiment frustrant que jshint refuse de terminer le traitement de mon fichier. Imaginez si grep s'arrêtait à mi-chemin en disant "trop de correspondances". C'est ce que je ressens en ce moment.

boronine le 6 juin 2013

👍2

Tous les 11 commentaires

Vous pouvez changer cela en définissant /*jshint maxerr: 1000 */ . Cela dit, ce serait bien si http://jshint.com permettait de changer cela en utilisant l'interface (mais je pense que c'est un bug pour le référentiel du site, et il y a quand même une nouvelle interface à venir, si je ne me trompe pas ).

Skalman le 3 juin 2011

Je suis d'accord, il devrait y avoir une option pour désactiver complètement cela. Marquage comme accepté.

valueof le 7 juin 2011

+1 Il devrait remplacer/étendre l'option "Arrêter à la première erreur".

gblazex le 19 juin 2011

Pouvons-nous fusionner cela?

mcandre le 1 mai 2013

Si vous regardez l'historique des commits, nous l'avons fusionné _il y a deux ans_ mais nous avons ensuite dû faire marche arrière car sur les gros scripts, JSHint serait trop lent.

valueof le 1 mai 2013

@antonkovalyov Ah, c'est logique.

Et si JSHint scannait les fichiers simultanément, en imprimant sur la console chaque fois qu'un fichier se terminait (avec mise en file d'attente pour que les fichiers ne soient pas intercalés) ? Cela pourrait résoudre JSHint étant trop lent, ainsi que réactiver cette option.

mcandre le 2 mai 2013

boronine le 6 juin 2013

👍2

Comme je l'ai dit plus haut, il s'agit d'une limitation technique.

valueof le 7 juin 2013

@antonkovalyov Voudriez-vous développer un peu la limitation technique ? Peut-être que moi (ou quelqu'un d'autre) pourrais écrire un patch qui plairait à tout le monde ? Je peux comprendre le souci d'un long processus en ce qui concerne l'installation de JSHint.com, mais d'après mon expérience de travail dans une base de code héritée, cette erreur n'est que trop familière :)

b-long le 23 juil. 2013

👍1

@b-long AFAIK, vous pouvez définir maxerr sur Infinity et vous pouvez regarder le script prendre une éternité.

goatslacker le 24 juil. 2013

Mon erreur, j'utilisais une configuration comme /*jshint maxerr: 200 */ plutôt que /*jshint maxerr:200 */ (avec JSHint 2.1.4) . L'espace après maxerr: m'a fait trébucher, il semble que maxerr doit être suivi (sans espaces) par les deux points et le nombre.

b-long le 24 juil. 2013

Cette page vous a été utile?

0 / 5 - 0 notes