wotan

El proyecto Fimbullinter

TypeScript y JavaScript Linter conectable

Paquetes disponibles

Wotan

El tiempo de ejecución de los deladores principales con un conjunto bien elegido de reglas Builtin. Personalizable con sus propias reglas, procesadores, formateros, configuraciones compartibles y módulos de complementos.

Consulte los documentos para obtener una explicación detallada de las reglas, configuración y uso disponibles.

Vé

Procesador oficial para componentes de archivo único VUE (SFC). Extrae el contenido de script de sus archivos *.vue para pelucas.

Heimdall

Capa de compatibilidad para permitir el uso de reglas y formatúas de TSLint dentro del tiempo de ejecución de Wotan.

Valtýr

Haga que Wotan se comporte casi como tslint. Reutilice su tslint.json existente sin ningún cambio.

Bifröst

Permite a los autores de las reglas y formatorios TSLInt proporcionar su paquete para el uso dentro de Wotan. Las reglas y formatters que usan Bifröst no necesitan Heimdall para funcionar correctamente.

Ymir

Proporciona tipos principales para reglas personalizadas y autores de complementos.

Mimir

Contiene todas las reglas centrales, formatters y presets de configuración.

Mithotyn

LanguageService Plugin para TypeScript. Proporciona pelusa en el editor en tiempo real mientras escribe.

Documentación adicional

• Comprender la API de TypeScript
• Reglas de escritura
• Reglas de prueba
• Usar reglas locales
• Escribir configuraciones compartibles
• Usando la API

Recetas

• Limpio de archivos VUE con reglas TSLint
• Reemplazo de tslint --type-check
• Detectar variables no utilizadas

¿De qué se trata todo esto?

¿Qué pasa con esos nombres?

Mitología nórdica:

Fimbullinter proviene de Fimbulwinter, los horribles 3 años que duran invierno que precede a los eventos de Ragnarök. 'Fimbul' significa 'The Great', 'Live' es una herramienta que detecta y advierte sobre ciertos patrones de codificación.

Wotan es uno de los muchos nombres de Odin, el padre. También puede conocerlo con el nombre de Woden, Wodan, Wensley, etc. Woden es un dios sacrificial, sediento de sangre y cruel. Se esfuerza constantemente por la sabiduría. Desde su trono puede ver que todo en los nueve mundos está sucediendo.

Vé es el más joven de los tres Bothers Woden, Vili y Vé que juntos mataron al gigante Ymir y crearon los nueve mundos de su cuerpo.

Para la primera pareja humana, pregunta y Embla, Odin dio alma y vida; Vili dio ingenio (inteligencia) y sentido del tacto; y Vé dio semblante (apariencia, expresión facial), discurso, audición y vista.

Heimdall (también conocido como Heimdallr), ubicado donde el puente ardiente del arco iris Bifröst se encuentra con el cielo, vigila el inicio de Ragnarök.

Bifröst es el puente ardiente arcoiris que conecta el mundo de los humanos con el reino de los dioses.

Valtýr , de "Valr" (los muertos, asesinado en la batalla) y "týr" (Dios), significa Dios de los asesinados y a menudo se usa para referirse a Odin.

Ymir es el gigante de cuyo cuerpo se creó el mundo entero. Él es el antepasado de todo Jötnar.

Mímir ("El recuerdo, el sabio") reconocido por su conocimiento y sabiduría. El dios Odin lleva la cabeza de Mimir y le recita el conocimiento secreto y el consejo.

Mithotyn (en realidad "Mitoðinn", que significa "dispensador del destino") introduce reglas donde no había ninguna. Llena el lugar de Odin durante sus viajes a tierras extranjeras.

¿Por qué otro linter más?

Este trata de evitar decisiones de diseño de otras revestimientos que resultaron ser problemáticas:

• Evite los conflictos de nombres prefijando nombres de reglas dependiendo del paquete del que vengan.
  • TSLINT pone todas las reglas en un espacio de nombres global y las busca en todos los directorios de reglas disponibles. El orden de los directorios es importante, mientras que las reglas básicas anulan la prioridad.
  • Eslint permite un directorio de reglas local como bandera CLI. Las reglas en ese directorio pueden anular las reglas centrales.
• Las dependencias de los archivos de configuración se resuelven en relación con ese archivo.
  • Tslint ya hace eso.
  • Eslint no admite eso.
• No hay distinción entre configuraciones y complementos compartibles. De hecho, ambas son solo configuraciones extensables que opcionalmente pueden proporcionar directorios de reglas, configuraciones, reglas y procesadores.
  • Tslint le permite elegir entre extends y rulesDirectory . El directorio de reglas de un paquete es un detalle de implementación y no debe ser parte de la configuración del usuario.
  • Eslint maneja las configuraciones y complementos bastante diferentes. De hecho, intentaron desaprobar las configuraciones compartibles a favor de los complementos.
• Carga perezosa de reglas para reducir el tiempo de inicio.
  • Tslint ya hace eso.
  • Eslint espera que los complementos proporcionen las reglas como objetos ya cargados. Eso causa muchas gastos generales si solo usa algunas reglas de un paquete grande.
• Almacenamiento en caché del acceso y configuración del sistema de archivos. Como el caché es un servicio DI, los usuarios de API pueden borrar el caché cuando sea necesario.
• Soporte para procesadores desde el principio. Habilitando la pelusa de *.vue archivos y muchos más.
• Alias ​​para reglas con configuración. Se puede utilizar para tratar reglas como no-resticted-syntax como reglas de nombre distintas para cada opción de configuración.
• Toda la API funciona con un contenedor DI. Eso facilita la inyección de un servicio diferente. Incluso puede usar complementos a través de la CLI para inyectar diferentes servicios.
• Archivo de configuración "global" (además de .wotanrc.yaml ) para los valores predeterminados de CLI y la configuración del complemento: .fimbullinter.yaml . Este archivo también puede ser utilizado por los complementos del editor, por lo que no hay necesidad de duplicar la configuración común.
  • Eslint no tiene dicho archivo y se negó a agregar uno en el futuro. Herramientas como standard o xo no tendrían que existir si solo necesitara crear un archivo de configuración de este tipo con valores predeterminados de CLI.
  • TSLINT Startet para meterlo en su tslint.json , lo que lleva a usuarios confundidos.
• Informe los comentarios no utilizados y redundantes de habilitar y deshabilitar (o partes de los mismos) con --report-useless-directives .
  • Eslint informa solo los comentarios de desactivación no utilizada. Solo informa comentarios que están completamente no utilizados. Los comentarios redundantes no se informan, así como habilitan comentarios para reglas inexistentes.
  • Tslint no admite eso.

Diferencias a Tslint

• Para extender un complemento o configuración compartible, use extends: plugin-name . El nombre se resolverá de acuerdo con el algoritmo de resolución del módulo del nodo en relación con el archivo de configuración.
• Para usar las reglas mantenidas dentro de su proyecto, use rulesDirectory: {"my-prefix": "./path/to/rules"} y configúrelas como my-prefix/rule-one: "error" . El directorio de reglas es una ruta relativa al archivo de configuración.
• Anulaciones: puede anular la cofiguración principal especificando una o más anulaciones. Si el nombre de archivo coincide con el patrón global de la anulación, se aplican todas las configuraciones proporcionadas por esa anulación. Las anulaciones se procesan en orden, más tarde anular la configuración de anulación de las anulaciones anteriores.
  • Los patrones coinciden en relación con el archivo de configuración en el que se especifican.
  • Los patrones sin barras solo coinciden con el nombre de base de cada archivo.
  • Para limitar una coincidencia al directorio actual, prefijo el patrón con ./ .
  • Los patrones negados se pueden usar para restar de las coincidencias de patrones anteriores.
• linterOptions.exclude -> exclude
  • Las exclusiones no se anulan al extender una configuración.
  • La coincidencia de patrones sigue las mismas reglas que las anulaciones (ver arriba).
• JSON5 Soporte para archivos de configuración.
• Configuración independiente de las reglas que las reglas y procesadores pueden recoger.
• Procesadores, incluso soportes --project .
• Alias, ver arriba
• Un enfoque sensato y seguro para la reparación:
  • No corregirá archivos con errores de sintaxis.
  • Excluye reemplazos superpuestos para evitar destruir su código.
  • Ejecuta un número configurable de iteraciones por archivo para aplicar cambios conflictivos en la próxima iteración.
  • Se detiene si las correcciones introducirían errores de sintaxis.
  • La fijación con --project no crea todo el programa desde cero, lo que lo hace muy rápido.
• Pruebas
  • Las pruebas se configuran en archivos JSON que pueden configurar todo lo que puede especificar aunque el CLI
  • Los archivos de prueba no contienen marcado de error. Eso evita los errores de sintaxis y los hace más fáciles de mantener. Los resultados de la pelusa y el contenido fijo se almacenan en archivos de referencia separados.
  • El mismo código se puede probar con diferentes configuraciones.
• Admite referencias de proyecto TypeScript.
• Carga valores predeterminados para opciones de CLI desde .fimbullinter.yaml .
• No utiliza información de tipo en archivos JavaScript no verificados ( // @ts-nocheck o "checkJs": false ).
• Informes no utilizados y redundantes Habilitar y deshabilitar los comentarios con --report-useless-directives .

Entornos compatibles

Este proyecto se ejecuta en todas las versiones compatibles activamente de Node.js.

Este proyecto admite oficialmente la última versión estable de TypeScript. Al momento de escribir esto es 3.0 - 3.2. Debería funcionar con las compilaciones nocturnas de TypeScript ( typescript@next ), pero no hay garantía.

Las reglas personalizadas deben usar al menos ES6 para tener soporte para clases nativas. De lo contrario, se encuentra con problemas al intentar extender las clases exportadas desde cualquiera de los paquetes.

Versiones semánticas (política de Semver)

️ La siguiente política solo se aplica para el 1.x y las siguientes lanzamientos. Cada liberación en el rango 0.x se considera experimental. Puede y romperá los cambios de API sin depreciación.

En teoría, cada cambio a una regla puede romper a los usuarios y podría considerarse un cambio de ruptura. Para evitar liberar una nueva versión principal para cada corrección de errores, tenemos pautas ligeramente diferentes como se describe a continuación.

Prereleases (construcciones nocturnas)

• no se garantiza que sea estable
• Etiquetado como next en NPM para que pueda instalar @fimbul/wotan@next
• contiene los últimos cambios destinados a la próxima versión
  • x.0.0-dev* contiene todos los cambios, incluidos los rompientes para la próxima versión principal
  • xy0-dev* contiene todos los cambios para la próxima versión menor
  • No hay prerelebras para versiones de parche

Comunicados de parche

• Frascos de soluciones
• corrige regresiones
• Refactorizaciones de la funcionalidad interna que no cambian el comportamiento de los usuarios

Lanzamientos menores

• Agrega nuevas reglas, opciones de reglas, formatters, procesadores, API
• Las reglas pueden agregar nuevos cheques que pueden conducir a nuevos hallazgos
• Las nuevas reglas y opciones están habilitadas en wotan:latest
• Las reglas pueden cambiar sus mensajes de búsqueda
• Los formatorios destinados a la consumo humano (por ejemplo, stylish ) pueden cambiar su producción
• Reglas, opciones de reglas, formateros, procesadores y API pueden estar en desuso
• Se pueden agregar nuevas opciones de configuración a los archivos de configuración

Lanzamientos principales

• contiene cambios de API de ruptura
• Elimina reglas, opciones, formators, etc. previamente desaprobadas, etc.
• Formatters destinados al consumo de la máquina (por ejemplo, json o tap ) puede cambiar su salida
• wotan:recommended se actualiza al contenido de wotan:latest

Horario de lanzamiento

Actualmente no hay un cronograma de lanzamiento fijo. Las construcciones nocturnas se publican todas las noches si hay cambios en Master. Las versiones de parche se publican tan pronto como se identifican y solucionan los errores. Las versiones menores se publican cada semana o dos si hay cambios en Master. Los principales lanzamientos se publican una vez que se han acumulado suficientes cambios de ruptura.

Licencia

Apache-2.0 © Klaus Meinhardt