Existe-t-il des outils d'analyse statique JavaScript? [fermé]

J'ai l'habitude de voir mon compilateur se plaindre quand je fais quelque chose de stupide comme une faute de frappe sur un nom de variable, mais JavaScript a l'habitude de laisser passer cela.

Existe-t-il des outils d'analyse statique pour JavaScript?

Je conviens que JSLint est le meilleur point de départ. Notez que JavaScript Lint est distinct de JSLint . Je suggérerais également de vérifier JSure , qui, dans mes tests limités, a fait mieux que l'un ou l'autre, mais avec quelques aspérités dans l'implémentation - la version Intel Mac s'est écrasée au démarrage pour moi, bien que la version PowerPC fonctionne bien même sur Intel, et la version Linux fonctionnait bien aussi. (Le développeur, Berke Durak, a dit qu'il me recontacterait une fois le problème résolu, mais je n'ai pas entendu parler de lui.)

N'attendez pas autant de l'analyse statique JavaScript que d'un bon vérificateur C. Comme me l'a dit Durak, "toute analyse non triviale est très difficile en raison de la nature dynamique de Javascript."

(Un autre bogue, encore plus obscur pour Mac uniquement, cette fois avec le widget Konfabulator de JSLint: faire glisser une icône de document BBEdit sur le widget déplace le document vers la corbeille. Le développeur, Douglas Crockford, n'avait pas essayé le widget sur un Mac.)

10 août 2009: Aujourd'hui au Static Analysis Symposium , Simon Holm Jensen a présenté un article sur TAJS: Type Analyzer for JavaScript , écrit avec Anders Møller et Peter Thiemann. Le papier ne mentionne pas les outils ci-dessus, mais Jensen m'a dit qu'il avait regardé certains d'entre eux et qu'il n'était pas impressionné. Le code pour TAJS devrait être disponible cet été.

RÉPONSE MIS À JOUR, 2017: Oui. Utilisez ESLint. http://eslint.org

En plus de JSLint (déjà mentionné dans la réponse de Flash Sheridan ) et du compilateur Closure (précédemment mentionné dans la réponse de awhyte ), j'ai également tiré beaucoup d'avantages de l'exécution de JSHint et de PHP CodeSniffer . Depuis 2012, les quatre outils sont gratuits et open-source et ont derrière eux une grande communauté de développeurs active. Ils sont chacun un peu différents (et je pense, complémentaires) dans les types de contrôles qu'ils effectuent:

JSLint a été conçu pour être et est toujours l'outil de peluchage personnel de Douglas Crockford. Il est livré avec un excellent ensemble de règles par défaut - celui de Crockford, constamment mis à jour alors qu'il continue à en apprendre davantage sur JavaScript et ses pièges. JSLint est très opiniâtre et cela est généralement considéré comme une bonne chose. Ainsi, il y a (intentionnellement) une quantité limitée que vous pouvez faire pour configurer ou désactiver des règles individuelles. Mais cela peut rendre difficile l'application de JSLint au code hérité.

JSHint est très similaire à JSLint (en fait, il a commencé sa vie en tant que fork de JSLint) mais il est plus facile / possible de configurer ou de désactiver toutes les vérifications de JSLint via les options de ligne de commande ou via un .jshintrcfichier .

J'aime particulièrement pouvoir dire à JSHint de signaler toutes les erreurs d'un fichier, même s'il y a des centaines d'erreurs. En revanche, bien que JSLint ait une maxerroption de configuration, il sera généralement renfloué relativement tôt lors de la tentative de traitement de fichiers contenant un grand nombre d'erreurs.

Le compilateur Closure est extrêmement utile dans la mesure où, si le code ne se compile pas avec Closure, vous pouvez vous sentir très certain que ledit code est profondément arrosé d'une manière fondamentale. La compilation de clôture est peut-être la chose la plus proche du monde JS d'une vérification de syntaxe "interpréteur" comme php -louruby -c

Closure vous avertit également des problèmes potentiels tels que des paramètres manquants et des variables non déclarées ou redéfinies. Si vous ne voyez pas les avertissements attendus, essayez d'augmenter le niveau d'avertissement en appelant Closure avec une option de--warning_level VERBOSE

PHP CodeSniffer peut analyser JavaScript ainsi que PHP et CSS. CodeSniffer est livré avec plusieurs normes de codage différentes, (disons phpcs -ipour les voir) qui incluent de nombreux sniffs utiles pour le code JavaScript, y compris des vérifications par rapport aux structures de contrôle en ligne et aux espaces superflus .

Voici une liste des sniffs JavaScript disponibles dans PHP CodeSniffer à partir de la version 1.3.6 et voici un ensemble de règles personnalisées qui vous permettrait de les exécuter tous en même temps. À l'aide de jeux de règles personnalisés, il est facile de choisir les règles que vous souhaitez appliquer. Et vous pouvez même écrire vos propres sniffs si vous souhaitez appliquer un "style maison" particulier qui n'est pas pris en charge par défaut. Afaik CodeSniffer est le seul des quatre outils mentionnés ici qui prend en charge la personnalisation et la création de nouvelles règles d'analyse statique. Une mise en garde cependant: CodeSniffer est également le plus lent de tous les outils mentionnés.

Le compilateur JS "Closure" de Google produit des avertissements et des erreurs configurables au moment de la compilation. Il trouve définitivement des variables et des méthodes mal orthographiées, ainsi que des erreurs d'arité. Si vous êtes prêt à écrire JsDoc de manière Closure, il peut également faire beaucoup avec les informations de type.

L'outil "Compressor" de YUI peut également produire des avertissements, mais ne l'a pas encore essayé.

Je n'ai pas eu beaucoup de chance avec l'IDE Aptana, construit sur Eclipse, mais d'autres personnes l'aiment. Voir la discussion Stack Overflow sur les IDE JS.

L'IDE IntelliJ, qui n'est pas gratuit la dernière fois que j'ai vérifié, a un excellent support JS. Il détectera et mettra en évidence les variables et méthodes mal orthographiées au fur et à mesure que vous tapez, et plus encore. Il a aussi la saisie semi-automatique.

En résumé, JSLint, JSHint, Plato, ESLint, Google Closure-Linter sont les outils disponibles. J'ai rencontré des problèmes d'installation en essayant Google Closure-Linter pour Windows. Mais, il mentionne sur la page Web que sa prise en charge de Windows est expérimentale. J'ai trouvé et essayé un autre outil qui fonctionne bien. Voici le lien pour cela: http://esprima.org/

C'est aussi le lien github pour l'outil Esprima: https://github.com/ariya/esprima

Vous pouvez voir quelques outils pour l'analyse de code statique JavaScript dans ce wiki .

Un outil dans le Wiki, mais non mentionné dans cet article, est DeepScan . Son objectif est de trouver les erreurs d'exécution et les problèmes de qualité plutôt que les conventions de codage des linters. Il couvre également TypeScript, React et Vue.js.

Vous pouvez l'essayer pour votre projet GitHub.

J'ai essayé ESlint et je l'ai trouvé bon ... vous pouvez également y ajouter des règles personnalisées ... Voici le repo github: https://github.com/nzakas/eslint et voici l'introduction: http: // www. nczonline.net/blog/2013/07/16/introducing-eslint/

Plus axé sur la sécurité que la liste à usage général peut être trouvé sur le Mozilla Wiki à Security / B2G / JavaScript code analysis

Le but de ce document est de collecter des outils d'analyse de code JavaScript pouvant être inclus dans les projets Mozilla à venir ou pour un usage interne.

Il existe également au moins un produit commercial qui effectue une analyse de sécurité: Burp obtient de nouvelles capacités d'analyse JavaScript

La dernière version de Burp comprend un nouveau moteur d'analyse statique du code JavaScript. Cela permet à Burp Scanner de signaler une série de nouvelles vulnérabilités, notamment:

• XSS basé sur DOM
• Injection JavaScript
• Injection SQL côté client
• Détournement de WebSocket
• Manipulation du chemin du fichier local
• Redirection ouverte basée sur DOM
• Manipulation des cookies
• Manipulation de l'en-tête de la requête Ajax
• Déni de service basé sur DOM
• Manipulation des messages Web
• Manipulation du stockage HTML5

Dans le domaine commercial, Coverity Static Analysis prend en charge l'analyse de JavaScript à partir de la version 7.7 (mi-2015). En ce qui concerne votre demande spécifique sur les fautes de frappe, mon projet favori apparaissant dans la dernière version (8.0, début 2016) trouve des fautes de frappe dans les noms des éléments du programme.

En tant que développeur clé du projet, veuillez accepter mon argument éhonté: bien que pas encore aussi mature que l' analyse vénérée C / C ++ , l'analyse JavaScript de Coverity partage en grande partie le même moteur, avec le même objectif sur la recherche de défauts de grande valeur avec un faible taux de rapports de faux positifs. Nous nous concentrons de plus en plus sur la recherche de défauts de sécurité dans JavaScript (et d'autres langages), en plus de trouver des erreurs de programmation générales.

Maintenant, voici quelques fautes de frappe qu'il trouve (faute de frappe exacte laissée comme exercice pour le lecteur, pour souligner à quel point elles peuvent être facilement ignorées):

merge.js: (lien stable) (dernière révision)

commandes-packages-query.js: (lien stable) (dernière révision)

series-pie-tests.js: (lien stable) (dernière révision)

contour_case.js: (lien stable) (dernière révision)

J'aime Jslint pour ce genre de chose ...

Flow effectue une analyse statique avec et sans annotations.

Si vous avez besoin d'annotations, la syntaxe est compatible avec TypeScript .

Installez le package avec:

npm install --global flow-bin

Il y a aussi des outils. Jetez un œil à gulp-flowtype et peut - être SublimeLinter-flow

JSAnalyse vient d'être publié sur codeplex. C'est un outil qui analyse les dépendances entre les fichiers javascript. Vous pouvez même définir les dépendances autorisées et JSAnalysis vérifie si les règles définies sont remplies ou non. Cela permet de garder une trace des dépendances javascript même dans les gros projets et d'avoir une architecture propre.

JSAnalyse peut être exécuté en tant qu'outil de ligne de commande ou configuré via le diagramme de couches Visual Studio. Il est également facile à intégrer dans la construction. Avec les enregistrements fermés, vous pouvez garder les dépendances sous contrôle.

http://jsanalyse.codeplex.com/

Notre SD ECMAScript CloneDR est un outil pour trouver des copies exactes et quasi-manquantes de code dupliqué sur de grandes bases de code source JavaScript.

Il utilise la syntaxe du langage pour guider la détection, il trouvera donc des clones malgré les changements de format, les commentaires insérés / supprimés, les variables renommées et même certaines instructions insérées / supprimées.

Le site a un exemple de CloneDR exécuté sur la bibliothèque Closure de Google.

Divulgation complète, je suis derrière ceci: http://www.toptensoftware.com/minime qui fait la minification, l'obscurcissement et un ensemble raisonnable de contrôles de style de charpie.