Existe-t-il des outils d'analyse statique JavaScript?
J'ai l'habitude de voir mon compilateur se plaindre lorsque 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 suis d'accord que JSLint est le meilleur endroit pour commencer. Notez que JavaScript Lint est différent de JSLint . Je suggérerais également de vérifier JSure , ce qui, dans mes tests limités, a fait mieux que l'un ou l'autre, mais avec quelques irrégularités dans la mise en œuvre - la version Intel Mac s'est bloquée au démarrage pour moi, bien que le PowerPC la version fonctionnait bien même sur Intel, et la version Linux fonctionnait également bien. (Le développeur, Berke Durak, a dit qu'il me recontacterait quand cela aurait été corrigé, mais je n'ai pas eu de ses nouvelles.)
N'attendez pas autant de l'analyse statique JavaScript que d'un bon vérificateur C. Comme Durak me l'a dit, "toute analyse non triviale est très difficile en raison de la nature dynamique de Javascript."
(Un autre bug 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 dans la corbeille. Le développeur, Douglas Crockford, n'avait pas essayé le widget sur 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 document ne mentionne pas les outils ci-dessus, mais Jensen m'a dit qu'il avait regardé certains d'entre eux et n'était pas impressionné. Le code pour TAJS devrait être disponible cet été.
RÉPONSE MISE À JOUR, 2017: Oui. Utilisez ESLint. http://eslint.org
En plus de JSLint (déjà mentionné dans Flash Sheridan's answer ) et Closure compiler (précédemment mentionné dans awhyte's answer ) J'ai également beaucoup profité de l'exécution de JSHint et PHP CodeSniffer . Depuis 2012, les quatre outils sont gratuits et ont une communauté de développeurs importante et active derrière eux. 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 personnel de linting de Douglas Crockford. Il est livré avec un super jeu de règles par défaut - Crockford propre, constamment mis à jour comme il continue d'apprendre à propos de JavaScript et de ses pièges. JSLint est hautement opinionné et c'est généralement vu comme une bonne chose. Il y a donc (intentionnellement) un quantité limitée que vous pouvez faire pour configurer ou désactiver 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 comme fourche JSLint) mais il est plus facile/possible de - configurer ou désactiver toutes les vérifications de JSLint via les options de ligne de commande ou via un .jshintrc fichier .
J'aime particulièrement que je puisse dire à JSHint de signaler tout des erreurs dans un fichier, même s'il y a des centaines d'erreurs. En revanche, bien que JSLint ait une option de configuration maxerr, 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 le sera pas compiler avec Closure, vous pouvez être très certain ledit code est profondément arrosé d'une manière fondamentale. La compilation de la fermeture est probablement la chose la plus proche dans le monde JS à une vérification de syntaxe "interprète" comme php -l ou Ruby -c
Fermeture également vous avertit des problèmes potentiels tels que les paramètres manquants et les variables non déclarées ou redéfinies. Si vous ne voyez pas les avertissements que vous attendez, 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 différentes normes de codage (disons phpcs -i pour les voir) qui incluent de nombreux reniflements utiles pour le code JavaScript, y compris des vérifications par rapport à structures de contrôle en ligne et espaces blancs superflus .
Voici une liste des sniff JavaScript disponible dans PHP CodeSniffer à partir de la version 1.3.6 et voici un jeu de règles personnalisé qui vous permettrait de les exécuter) tout à la fois. En utilisant des ensembles de règles personnalisés, il est facile de choisir et choisir les règles vous voulez appliquer. Et vous pouvez même écrire vos propres reniflements si vous voulez appliquer un "style maison" particulier qui n'est pas pris en charge dès le départ. Afaik CodeSniffer est le seul outil des quatre 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 l'un des outils mentionnés.
compilateur JS "Closure" de Google génère 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 la manière Closure, cela peut aussi faire beaucoup avec les informations de type.
L'outil YUI "Compressor" peut également générer 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 des 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 de la frappe, et plus encore. Il a également une 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 lors de l'essai de Google Closure-Linter pour Windows. Mais, il mentionne sur la page Web que son support pour Windows est expérimental. J'ai trouvé et essayé un autre outil qui fonctionne bien. Voici le lien pour cela: http://esprima.org/
Aussi, c'est 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 du 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 dépôt github: https://github.com/nzakas/eslint et voici son introduction : http://www.nczonline.net/blog/2013/07/16/introducing-eslint/
Dans le domaine commercial, Analyse statique de la couverture prend en charge l'analyse de JavaScript à partir de la version 7.7 (mi-2015). Concernant votre demande spécifique sur les fautes de frappe, mon projet animal 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 plug sans vergogne: bien que pas encore aussi mature que le analyse vénérée C/C++ , l'analyse JavaScript de Coverity partage une grande partie du même moteur, avec le même accent sur la recherche défauts de grande valeur avec un faible taux de rapports de faux positifs. Nous mettons davantage l'accent sur la recherche de défauts de sécurité dans JavaScript (et dans 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 comme exercice pour le lecteur, pour souligner avec quelle facilité elles peuvent être 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)
Une liste plus axée sur la sécurité que la liste à usage général peut être trouvée sur le wiki Mozilla à l'adresse Analyse de code Sécurité/B2G/JavaScript
Le but de ce document est de collecter des outils d'analyse de code JavaScript adaptés pour être inclus dans des 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 pour l'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 WebSocket
- Manipulation du chemin du fichier local
- Redirection ouverte basée sur DOM
- Manipulation des cookies
- Manipulation d'en-tête de demande Ajax
- Déni de service basé sur DOM
- Manipulation des messages Web
- Manipulation du stockage HTML5
J'aime Jslint pour ce genre de chose ...
Flow fait 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 quelques outils. Jetez un oeil à 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 respectées ou non. Cela permet de garder une trace des dépendances javascript même dans les grands 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 build. Avec les enregistrements fermés, vous pouvez garder les dépendances sous contrôle.
Notre SD ECMAScript CloneDR est un outil pour trouver des copies exactes et presque 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 de fermeture de Google.
Divulgation complète, je suis derrière cela: http://www.toptensoftware.com/minime qui fait la minification, l'obscurcissement et un ensemble raisonnable de vérifications de style de peluches.