son - ¿Hay alguna herramienta de análisis estático de JavaScript?
ventajas de desactivar javascript (13)
Estoy acostumbrado a tener mi compilador quejarse cuando hago algo estúpido como un error tipográfico en un nombre de variable, pero JavaScript tiene la costumbre de dejar pasar esto.
¿Hay alguna herramienta de análisis estático para JavaScript?
Divulgación completa, estoy detrás de esto: http://www.toptensoftware.com/minime que hace la minificación, la ofuscación y un conjunto razonable de controles de estilo de pelusa.
En el ámbito comercial, Coverity Static Analysis admite el análisis de JavaScript a partir de la versión 7.7 (mediados de 2015). En cuanto a su consulta específica sobre errores tipográficos, mi proyecto favorito que aparece en la última versión (8.0, principios de 2016) encuentra errores tipográficos en los nombres de los elementos del programa.
Como desarrollador clave en el proyecto, acepte mi complemento desvergonzado: aunque aún no es tan maduro como el venerable análisis C / C ++ , el análisis de JavaScript de Coverity comparte mucho del mismo motor, con el mismo enfoque en encontrar defectos de alto valor con un bajo tasa de informes de defectos positivos falsos. Estamos aumentando nuestro enfoque en encontrar defectos de seguridad en JavaScript (y en otros idiomas), además de encontrar errores generales de programación.
Ahora, aquí hay algunos errores tipográficos que encuentra (error ortográfico exacto dejado como ejercicio para el lector, para enfatizar cuán fácilmente estos pueden pasarse por alto):
merge.js: (enlace estable) (última revisión)
commands-packages-query.js: (enlace estable) (última revisión)
series-pie-tests.js: (enlace estable) (última revisión)
outline_case.js: (enlace estable) (última revisión)
En resumen, JSLint, JSHint, Plato, ESLint, Google Closure-Linter son las herramientas disponibles. Tuve problemas de instalación al probar Google Closure-Linter para Windows. Pero, menciona en la página web que su soporte para Windows es experimental. Encontré y probé otra herramienta que funciona bien. Aquí está el enlace para ello: http://esprima.org/
Además, este es el enlace de Github para la herramienta Esprima: https://github.com/ariya/esprima
JSAnalyse acaba de ser publicado en codeplex. Es una herramienta que analiza las dependencias entre los archivos javascript. Incluso puede definir las dependencias permitidas y JSAnalysis verifica si las reglas definidas se cumplen o no. Eso permite hacer un seguimiento de las dependencias de javascript incluso en grandes proyectos y tener una arquitectura limpia.
JSAnalyse puede ejecutarse como una herramienta de línea de comandos o configurarse a través del Diagrama de Capa de Visual Studio. También es fácil de integrar en la construcción. Con check-ins cerrados puede mantener las dependencias bajo control.
Me gusta JSLint para este tipo de cosas ...
Nuestro SD ECMAScript CloneDR es una herramienta para encontrar copias exactas y casi fallidas de código duplicado en bases de código fuente JavaScript grandes.
Utiliza la sintaxis del lenguaje para guiar la detección, por lo que encontrará clones a pesar de los cambios de formato, los comentarios insertados / eliminados, las variables renombradas e incluso algunas afirmaciones insertadas / eliminadas.
El sitio tiene una muestra CloneDR ejecutada en la biblioteca de cierre de Google.
Probé ESlint y lo encontré bien ... también puede agregar reglas personalizadas allí. Aquí está el repositorio github: https://github.com/nzakas/eslint y aquí está la introducción: http://www.nczonline.net/blog/2013/07/16/introducing-eslint/
Puede ver algunas herramientas para el análisis de código estático de JavaScript en esta Wiki .
Una herramienta en el Wiki, pero no mencionada en esta publicación, es DeepScan . Su objetivo es encontrar errores de tiempo de ejecución y problemas de calidad en lugar de codificar convenciones de linters. Cubre también TypeScript y React.
Puedes probarlo para tu proyecto GitHub.
RESPUESTA ACTUALIZADA, 2017: Sí. Use ESLint. http://eslint.org
Además de JSLint (ya mencionado en la respuesta de Flash Sheridan ) y el compilador de Closure (mencionado anteriormente en la respuesta de awhyte ), también me he beneficiado mucho al ejecutar JSHint y PHP CodeSniffer . A partir de 2012, las cuatro herramientas son de código abierto gratuito y tienen una gran comunidad de desarrolladores activa detrás de ellas. Cada uno de ellos es un poco diferente (y creo que complementario) en el tipo de controles que realizan:
JSLint fue diseñado para ser, y sigue siendo, la herramienta personal de deshilado de Douglas Crockford. Incluye un excelente conjunto de reglas predeterminado, el de Crockford, que se actualiza constantemente a medida que continúa aprendiendo sobre JavaScript y sus peligros. JSLint es muy testarudo y esto generalmente se ve como algo bueno. Por lo tanto, hay (intencionalmente) una cantidad limitada que puede hacer para configurar o deshabilitar reglas individuales. Pero esto puede dificultar la aplicación de JSLint al código heredado.
JSHint es muy similar a JSLint (de hecho, comenzó su vida como fork JSLint) pero es más fácil / posible configurar o deshabilitar todas las comprobaciones de JSLint a través de las opciones de línea de comando o mediante un archivo .jshintrc .
Me gusta especialmente que pueda decirle a JSHint que informe todos los errores en un archivo, incluso si hay cientos de errores. Por el contrario, aunque JSLint tiene una opción de configuración de maxerr , en general rescatará relativamente temprano cuando intente procesar archivos que contengan grandes cantidades de errores.
El compilador Closure es extremadamente útil ya que, si el código no se compila con Closure, puede estar muy seguro de que dicho código está profundamente contaminado de alguna manera fundamental. La compilación de cierre es posiblemente lo más cercano que hay en el mundo de JS a una verificación de sintaxis de "intérprete" como php -l o ruby -c
El cierre también le advierte sobre posibles problemas , como la falta de parámetros y las variables no declaradas o redefinidas. Si no ve las advertencias que espera, intente aumentar el nivel de advertencia invocando Cierre con una opción de --warning_level VERBOSE
PHP CodeSniffer puede analizar JavaScript , PHP y CSS. CodeSniffer se envía con varios estándares de codificación diferentes, (digamos phpcs -i para verlos) que incluyen muchos olfagos útiles para el código de JavaScript, incluyendo controles contra estructuras de control en línea y espacios en blanco superfluos .
Aquí hay una lista de sniffs de JavaScript disponibles en PHP CodeSniffer a partir de la versión 1.3.6 y aquí hay un conjunto de reglas personalizado que le permite ejecutarlos todos a la vez. Con los conjuntos de reglas personalizados, es fácil seleccionar y elegir las reglas que desea aplicar. Incluso puede escribir sus propios olores si desea imponer un "estilo de casa" particular que no se admite de inmediato. Afaik CodeSniffer es la única herramienta de las cuatro mencionadas aquí que admite la personalización y la creación de nuevas reglas de análisis estático. Sin embargo, una advertencia: CodeSniffer es también el que funciona más lentamente con cualquiera de las herramientas mencionadas.
Se puede encontrar más información sobre la seguridad que la lista de propósitos generales en el Wiki de Mozilla en Security / B2G / JavaScript code analysis
El propósito de este documento es recopilar herramientas de análisis de código JavaScript adecuadas para incluir en proyectos futuros de Mozilla o para uso interno.
También hay al menos un producto comercial que realiza análisis de seguridad: Burp obtiene nuevas capacidades de análisis de JavaScript
La última versión de Burp incluye un nuevo motor para análisis estático de código JavaScript. Esto permite a Burp Scanner informar un rango de nuevas vulnerabilidades, que incluyen:
- XSS basado en DOM
- Inyección de JavaScript
- Inyección de SQL en el lado del cliente
- Secuestro webSocket
- Manipulación de ruta de archivo local
- Redirección abierta basada en DOM
- Manipulación de cookies
- Manipulación del encabezado de solicitud Ajax
- Denegación de servicio basada en DOM
- Manipulación de mensajes web
- Manipulación de almacenamiento HTML5
El compilador JS "Closure" de Google produce advertencias configurables y errores en tiempo de compilación. Definitivamente encuentra variables y métodos mal escritos, más errores de aridad. Si está dispuesto a escribir JsDoc the Closure, también puede hacer mucho con la información del tipo.
La herramienta YUI "Compresor" puede producir advertencias también, pero aún no lo ha probado.
No he tenido mucha suerte con el Aptana IDE, construido en Eclipse, pero a otras personas les gusta. Consulte la discusión de Desbordamiento de pila de los IDE de JS.
El IntelliJ IDE, que no es gratuito el último que verifiqué, tiene un excelente soporte JS. Detectará y resaltará vars mal escritos y métodos a medida que escribe, y más. También tiene autocompletar.
Flow realiza un análisis estático con y sin anotaciones.
Si necesita anotaciones, la sintaxis es compatible con TypeScript .
Instale el package con:
npm install --global flow-bin
También hay algunas herramientas. Eche un vistazo a gulp-flowtype y quizás SublimeLinter-flow
Estoy de acuerdo en que JSLint es el mejor lugar para comenzar. Tenga en cuenta que JavaScript Lint es distinto de JSLint . También sugiero comprobar JSure , que en mis pruebas limitadas fue mejor que cualquiera de ellos, aunque con algunas asperezas en la implementación: la versión Intel Mac se bloqueó en el inicio para mí, aunque la versión PowerPC funcionó bien incluso con Intel. y la versión de Linux corrió bien también. (El desarrollador, Berke Durak, dijo que me respondería cuando esto se solucionara, pero no he tenido noticias suyas).
No espere tanto del análisis estático de JavaScript como lo obtiene de un buen comprobador de C. Como me dijo Durak, "cualquier análisis no trivial es muy difícil debido a la naturaleza dinámica de Javascript".
(Otro error aún más oscuro, solo Mac, esta vez con el widget Konfabulator de JSLint: arrastrar un icono de documento BBEdit al widget mueve el documento a la papelera. El desarrollador, Douglas Crockford, no había probado el widget en una Mac).
10 de agosto de 2009: Hoy en el Simposio de análisis estático , Simon Holm Jensen presentó un trabajo sobre TAJS: Type Analyzer para JavaScript , escrito con Anders Møller y Peter Thiemann. El documento no menciona las herramientas anteriores, pero Jensen me dijo que había mirado a algunas y que no estaba impresionado. El código para TAJS debería estar disponible en algún momento de este verano.