Estoy acostumbrado a que mi compilador se queje cuando hago algo estúpido como un error tipográfico en el nombre de una variable, pero JavaScript tiene la costumbre de dejarlo pasar.
¿Existen herramientas de análisis estático para JavaScript?
Estoy acostumbrado a que mi compilador se queje cuando hago algo estúpido como un error tipográfico en el nombre de una variable, pero JavaScript tiene la costumbre de dejarlo pasar.
¿Existen herramientas de análisis estático para JavaScript?
Respuestas:
Estoy de acuerdo en que JSLint es el mejor lugar para comenzar. Tenga en cuenta que JavaScript Lint es distinto de JSLint . También te sugiero que eches un vistazo a JSure , que en mis pruebas limitadas funcionó mejor que cualquiera de ellos, aunque con algunas asperezas en la implementación: la versión Intel Mac se bloqueó al iniciar para mí, aunque la versión PowerPC funcionó bien incluso en Intel, y la versión de Linux también funcionó bien. (El desarrollador, Berke Durak, dijo que se pondría en contacto conmigo cuando esto estuviera arreglado, pero no he tenido noticias suyas).
No espere tanto del análisis estático de JavaScript como de un buen verificador 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 para 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 artículo 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 algunas de ellas y no estaba impresionado. El código de TAJS debería estar disponible en algún momento de este verano.
RESPUESTA ACTUALIZADA, 2017: Sí. Utilice ESLint. http://eslint.org
Además de JSLint (ya mencionado en la respuesta de Flash Sheridan ) y el compilador Closure (mencionado anteriormente en la respuesta de awhyte ), también he obtenido muchos beneficios al ejecutar JSHint y PHP CodeSniffer . A partir de 2012, las cuatro herramientas son de código abierto y cuentan con una comunidad de desarrolladores grande y activa detrás de ellas. Cada uno es un poco diferente (y creo que complementario) en los tipos de controles que realizan:
JSLint fue diseñado para ser y sigue siendo la herramienta personal de deshilachado de Douglas Crockford. Se envía con un gran conjunto de reglas predeterminado: el de Crockford, que se actualiza constantemente a medida que continúa aprendiendo sobre JavaScript y sus trampas. JSLint tiene muchas opiniones y esto generalmente se considera 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 una bifurcación JSLint) pero es más fácil / posible configurar o deshabilitar todas las comprobaciones de JSLint a través de las opciones de la línea de comandos o mediante un .jshintrc
archivo .
Particularmente me gusta que puedo decirle a JSHint que informe todos los errores en un archivo, incluso si hay cientos de errores. Por el contrario, aunque JSLint tiene una maxerr
opción de configuración, generalmente saldrá relativamente pronto al intentar procesar archivos que contienen una gran cantidad de errores.
El compilador de Closure es extremadamente útil porque, si el código no se compila con Closure, puede estar seguro de que dicho código está profundamente regado de alguna manera fundamental. La compilación de cierre es posiblemente lo más parecido que hay en el mundo JS a una verificación de sintaxis de "intérprete" como php -l
oruby -c
El cierre también le advierte sobre problemas potenciales , como parámetros faltantes y variables no declaradas o redefinidas. Si no ve las advertencias que espera, intente aumentar el nivel de advertencia invocando Closure con una opción de--warning_level VERBOSE
PHP CodeSniffer puede analizar JavaScript , así como PHP y CSS. CodeSniffer se envía con varios estándares de codificación diferentes, (digamos phpcs -i
para verlos) que incluyen muchos rastreos útiles para el código JavaScript, incluidas las verificaciones contra estructuras de control en línea y espacios en blanco superfluos .
Aquí hay una lista de rastreadores 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 permitiría ejecutarlos todos a la vez. Al usar conjuntos de reglas personalizados, es fácil elegir las reglas que desea aplicar. E incluso puede escribir sus propios olfatos si desea aplicar un "estilo de la casa" particular que no se admite de forma inmediata. 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 la más lenta de todas las herramientas mencionadas.
El compilador JS "Closure" de Google produce advertencias y errores configurables en tiempo de compilación. Definitivamente encuentra variables y métodos mal escritos, además de errores arity. Si está dispuesto a escribir JsDoc al modo de cierre, también puede hacer mucho con la información de tipo.
La herramienta YUI "Compressor" también puede generar advertencias, pero aún no la he probado.
No he tenido mucha suerte con Aptana IDE, construido sobre Eclipse, pero a otras personas les gusta. Consulte la discusión de Stack Overflow sobre JS IDE.
El IntelliJ IDE, que no es gratuito la última vez que lo comprobé, tiene un excelente soporte JS. Detectará y resaltará vars y métodos mal escritos a medida que escribe, y más. También tiene autocompletado.
En resumen, JSLint, JSHint, Plato, ESLint, Google Closure-Linter son las herramientas disponibles. Enfrenté problemas de instalación al probar Google Closure-Linter para Windows. Pero sí 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
Puede ver algunas herramientas para el análisis de código estático de JavaScript en este Wiki .
Una herramienta en Wiki, pero no mencionada en esta publicación, es DeepScan . Su objetivo es encontrar errores en tiempo de ejecución y problemas de calidad en lugar de convenciones de codificación de linters. También cubre TypeScript, React y Vue.js.
Puedes probarlo para tu proyecto de GitHub.
Probé ESlint y lo encontré bueno ... también puede agregar reglas personalizadas allí ... Aquí está el repositorio de github: https://github.com/nzakas/eslint y aquí está la introducción: http: // www. nczonline.net/blog/2013/07/16/introducing-eslint/
Se puede encontrar más seguridad centrada en la lista de propósito general en el Wiki de Mozilla en Análisis de código de seguridad / B2G / JavaScript
El propósito de este documento es recopilar herramientas de análisis de código JavaScript adecuadas para incluir en los próximos proyectos 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 el análisis estático de código JavaScript. Esto permite que Burp Scanner informe una serie de nuevas vulnerabilidades, que incluyen:
- XSS basado en DOM
- Inyección de JavaScript
- Inyección de SQL del lado del cliente
- Secuestro de WebSocket
- Manipulación de la 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
En el ámbito comercial, Coverity Static Analysis admite el análisis de JavaScript a partir de la versión 7.7 (mediados de 2015). Con respecto 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 del proyecto, acepte mi desvergonzado enchufe: aunque aún no es tan maduro como el venerado análisis C / C ++ , el análisis JavaScript de Coverity comparte gran parte del mismo motor, con el mismo enfoque en encontrar defectos de alto valor con un bajo tasa de informes de defectos falsos positivos. Estamos aumentando nuestro enfoque en encontrar defectos de seguridad en JavaScript (y otros lenguajes), además de encontrar errores generales de programación.
Ahora, aquí hay algunos errores tipográficos que encuentra (error tipográfico exacto dejado como ejercicio para el lector, para enfatizar la facilidad con que se pueden pasar por alto):
merge.js: (enlace estable) (última revisión)
command-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)
Me gusta Jslint para este tipo de cosas ...
Flow realiza análisis estáticos con y sin anotaciones.
Si necesita anotaciones, la sintaxis es compatible con TypeScript .
Instale el paquete con:
npm install --global flow-bin
También hay algunas herramientas. Eche un vistazo a gulp-flowtype y quizás a SublimeLinter-flow
JSAnalyse se acaba de publicar en codeplex. Es una herramienta que analiza las dependencias entre archivos javascript. Incluso puede definir las dependencias permitidas y JSAnalysis comprueba si las reglas definidas se cumplen o no. Eso permite realizar un seguimiento de las dependencias de JavaScript incluso en proyectos grandes y tener una arquitectura limpia.
JSAnalyse puede ejecutarse como una herramienta de línea de comandos o configurarse mediante Visual Studio Layer Diagramm. También es fácil de integrar en la construcción. Con los registros cerrados, puede mantener las dependencias bajo control.
Nuestro SD ECMAScript CloneDR es una herramienta para encontrar copias exactas y casi fallidas de código duplicado en grandes bases de código fuente JavaScript.
Utiliza la sintaxis del lenguaje para guiar la detección, por lo que encontrará clones a pesar de cambios de formato, comentarios insertados / eliminados, variables renombradas e incluso algunas declaraciones insertadas / eliminadas.
El sitio tiene una muestra de CloneDR ejecutada en la biblioteca Closure de Google.
Revelación completa, estoy detrás de esto: http://www.toptensoftware.com/minime que hace minificación, ofuscación y un conjunto razonable de controles de estilo de pelusa.