Stylelint: la hoja de estilo Linter que siempre quisimos

1. Por qué es importante la pelusa
2. Estilolint
3. Normas
4. Complementos
5. Archivos de configuración
6. Uso
   1. Línea de comando
   2. Trago
7. Conclusión
   1. Otras lecturas

Stylelint es un potente linter de hojas de estilo. Aporta claridad al código y le evita errores. Es útil para todos. Una vez que comiences a usarlo, no escucharás más comentarios como "Olvidaste eliminarlo allí". En este artículo, Aleks Hudochenkov le mostrará por qué es importante utilizar linting en una hoja de estilo, cómo stylelint pone orden en una hoja de estilo y cómo podemos evitar errores. Feliz desarrollo y que tengas una revisión pacífica del código.

Todo el mundo quiere una base de código limpia y coherente, sin importar el idioma. Los desarrolladores están acostumbrados a configurar linters en lenguajes de programación como JavaScript y Python, pero rara vez utilizan un linter para hojas de estilo. En este artículo, veremos stylelint , un linter para hojas de estilo.

Aprenderemos por qué es importante aplicar linting a una hoja de estilo, cómo stylelint pone orden en una hoja de estilo y cómo podemos evitar errores. Finalmente, aprenderemos a usar stylelint y comenzaremos a usar linting lo antes posible.

Por qué es importante la pelusa

Un linter es una herramienta que analiza código e informa errores cuando un fragmento de código no pasa las reglas definidas en la configuración del linter.

Muchos de nosotros trabajamos en bases de código a las que muchas personas tienen acceso. Si no se siguen reglas estrictas sobre el estilo de codificación, el código podría convertirse en un desastre muy rápidamente. Tal vez su código ya sea un desastre y desee limpiarlo y mantenerlo limpio con el tiempo. Incluso si trabaja únicamente con hojas de estilo, querrá que el código sea coherente.

Por supuesto, es posible que su equipo tenga reglas de estilos de código escritas en texto plano en alguna wiki en alguna parte. Pero siempre hay que tener en cuenta el factor humano: la gente comete errores, nunca a propósito.

E incluso si está obsesionado con seguir las reglas de un estilo de codificación adecuado, es posible que sus colegas o contribuyentes a su proyecto de código abierto no lo estén. Sin un linter, usted mismo deberá verificar el código en busca de estilos y errores. Nadie debería dedicar tiempo a cosas que pueden automatizarse. Un linter disminuirá significativamente el tiempo dedicado a la revisión del código porque no perderá tiempo revisando estilos y escribiendo un montón de comentarios sobre cada error. Podrás examinar libremente qué hace el código y cómo se ve.

Estilolint

Stylelint es un potente y moderno linter de hojas de estilo escrito en JavaScript por David Clark , Richard Hallows , Evilebot Tnawi y la comunidad . Es poderoso en su velocidad, variedad y calidad de reglas, y es totalmente carente de opiniones . Stylelint tiene más de cien reglas y el número va en aumento. Pero no temas: todas las reglas están deshabilitadas de forma predeterminada y tú habilitas solo las que quieras. Stylelint puede modificar no solo CSS sino también Sass , SugarSS y cualquier otra sintaxis que PostCSS pueda analizar (porque stylelint se basa en ella).

Stylelint es para las hojas de estilo lo que ESLint es para JavaScript.

Normas

Stylelint tiene más de cien reglas , que se pueden dividir en tres grupos: reglas de estilo , reglas de mantenimiento del código y reglas que verifican errores que cambiarían lo que hace el código en un navegador. Las reglas de estilo verifican el espaciado (como alrededor de los dos puntos), los saltos de línea, la sangría, etc. Las reglas de mantenimiento pueden informar si se usa un ID en un selector o si la !importantpalabra clave se usa en una declaración. Las reglas para verificar errores pueden informar un color HEX incorrecto o una propiedad abreviada que anula otra declaración.

No repasaré aquí las reglas de estilo (hay muchísimas). Más bien, quiero describir algunas de las reglas que ayudan con el mantenimiento y previenen errores.

La regla para evitar que las propiedades abreviadas anulen otras declaraciones (o, en el lenguaje de Stylelint, declaration-block-no-shorthand-property-overrides) evitaría una situación como esta:

div { padding-left: 20px; /* This property is overridden. */ padding: 10px;}

Stylelint también evita colores HEX no válidos ( color-no-invalid-hex):

p { color: #44;}

Y evita propiedades duplicadas ( declaration-block-no-duplicate-properties):

p { color: #000; /* This property is overridden. */ margin: 0 0 1.25em; color: #777;}

Puede utilizar la sintaxis antigua para los degradados. Stylelint lo comprobará ( function-linear-gradient-no-nonstandard-direction):

/* incorrect property */.block { background: linear-gradient(bottom, #fff, #000);}/* correct property */.block { background: linear-gradient(to bottom, #fff, #000);}

El uso de la !importantpalabra clave en una propiedad puede causar problemas en el futuro cuando necesite anular la propiedad con otra regla. Simplemente evítelo !importantpor completo con la declaration-no-importantregla.

El uso de un ID en un selector ( #main) y el uso de un selector de tipo (es decir, un selector basado en un elemento HTML, por ejemplo, .block p) podrían estar prohibidos en su metodología de desarrollo (por ejemplo, BEM ). En este caso, selector-no-idy selector-no-typeserá útil.

A veces escribirás mal algo u olvidarás agregar algo a una hoja de estilo. En el caso de una animación, no-unknown-animationsinformará si el nombre de una animación no tiene @keyframesuna regla correspondiente.

¿Y por qué querrías preocuparte por los prefijos en los valores, los nombres de las propiedades y los selectores cuando tenemos Autoprefixer ? Deje que Autoprefixer se encargue de eso y evite que se agreguen prefijos con las value-no-vendor-prefixreglas property-no-vendor-prefixy selector-no-vendor-prefix.

Por supuesto, hay muchas más reglas en stylelint.

Complementos

Además de las reglas predeterminadas, stylelint también admite complementos, por lo que puedes ampliarlo con nuevas reglas. No hay muchos complementos disponibles en este momento, pero los que tenemos son muy útiles.

A veces los desarrolladores anidan demasiado. Si bien todos los preprocesadores admiten el anidamiento, el anidamiento de reglas muy profundas da como resultado una mayor especificidad del selector y genera problemas con el mantenimiento de esas reglas. Aquí está un ejemplo típico:

.header { .nav { .item { .link { color: blue; :hover { color: red; } } } }}

Esto se traduce de la siguiente manera:

.header .nav .item .link { color: blue;}.header .nav .item .link:hover { color: red;}

Stylelint no tiene una regla para este problema lista para usar, pero hay un complemento ( stylelint-statement-max-nesting-depth) que agrega una regla para la profundidad de anidamiento.

Para utilizar cualquier complemento, instálelo primero:

npm install stylelint-statement-max-nesting-depth --save-dev

Luego, agregue el complemento al archivo de configuración en la pluginsmatriz. Añade la nueva regla y configúrala: Fulares para bebés

{ "plugins": [ "stylelint-statement-max-nesting-depth" ], "rules": { "statement-max-nesting-depth": 2 }}

En la configuración anterior, hemos establecido la profundidad de anidamiento en un máximo de dos. Por lo tanto, se nos pedirá que simplifiquemos nuestro ejemplo anterior a una profundidad de anidamiento menor (en este caso, dos niveles):

.nav { .link { color: blue; :hover { color: red; } }}

O podríamos simplificar aún más a un nivel:

.nav-link { color: blue; :hover { color: red; }}

No repasaré todos los complementos aquí, sino que recomendaré algunos:

• Evite selectores calificados , como ul.nav, div#mainy input[type="submit"]. (Cada opción se puede habilitar por separado).
• Aplique valores abreviados siempre que sea posible.
• Si sigue la metodología BEM o SUIT, es posible que desee comprobar la validez de sus selectores. El complemento stylelint-selector-bem-pattern tiene patrones predefinidos para BEM y SUIT y se puede configurar para otras metodologías.

Si desea una nueva regla, puede escribir su propio complemento .

Archivos de configuración

La configuración es la parte más difícil del uso de un linter y la que requiere más tiempo. Pero existen atajos y diferentes estrategias que hacen que stylelint sea más fácil de configurar.

Su configuración puede llegar a ser muy grande, por lo que la forma más conveniente de almacenar la configuración de stylelint es en un archivo JSON separado, llamado .stylelintrc. De esta manera, el archivo se puede utilizar en la interfaz de línea de comandos, en una herramienta de compilación y en un editor de código.

Una configuración muy simple podría verse así:

{ "rules": { "color-hex-case": "lower", "color-hex-length": "short", "color-no-invalid-hex": true }}

Hay tres estrategias para la configuración. La primera , sencilla, es ampliar la configuración de otra persona (que admite stylelint) y luego agregar, deshabilitar o modificar las reglas que desea cambiar. Los desarrolladores han creado configuraciones que probablemente se ajusten a la mayoría de las necesidades. Puedes instalar uno como un paquete npm:

npm install stylelint-config-standard --save-dev

Luego, en su propio archivo de configuración, ampliaría el de ellos y anularía cualquier regla según fuera necesario:

{ "extends": "stylelint-config-standard", "rules": { "indentation": "tab", "number-leading-zero": null }}

En este ejemplo, ampliamos stylelint-config-standardy cambiamos la indentationregla para que sea "pestañas" y la deshabilitamos number-leading-zero.

Puede ampliar no solo las configuraciones compartidas a través de npm, sino también las locales. La documentación tiene más información sobre cómo ampliar y compartir configuraciones .

La segunda estrategia es comenzar con un archivo vacío y progresar lentamente agregando reglas a medida que las necesite. Por ejemplo, es posible que todavía no te importe el estilo de codificación y solo quieras concentrarte en prevenir errores:

{ "rules": { "color-no-invalid-hex": true, "declaration-block-no-duplicate-properties": true, "declaration-block-no-shorthand-property-overrides": true, "function-linear-gradient-no-nonstandard-direction": true }}

Más adelante podrás agregar más reglas.

La tercera estrategia es repasar todas las reglas y configurarlas todas. Prefiero esta estrategia porque quiero comprobar tanto como sea posible y utilizar stylelint en toda su potencia. Claro, es la estrategia que requiere más tiempo, pero produce el mejor resultado. Para hacerlo más fácil, los desarrolladores de stylelint han creado un archivo de configuración de ejemplo con todas las reglas.

Cada regla habilitada tiene una gravedad de error. Esto significa que cualquier regla que no se cumpla no pasará la prueba. El nivel de gravedad de cualquier regla se puede reducir a una advertencia, lo que evitará que falle una prueba. Esto es útil si acaba de introducir una regla y no desea que una compilación falle mientras el equipo se está adaptando a la nueva regla.

{ "rules": { "color-hex-case": ["lower", { "severity": "warning" }] }}

En este ejemplo, stylelint advertirá si un color HEX está mal escrito, pero no generará un error.

A veces necesitamos poner algo en una hoja de estilo que nuestra configuración de estilo prohíbe. Por ejemplo, tenemos prohibido usar la !importantpalabra clave, pero es posible que necesitemos usarla en un lugar para anular algún widget de terceros. No queremos desactivar la regla debido a este caso excepcional. Pero tampoco nos gustaría ver el error cada vez. Por suerte, podemos desactivar una regla particular en una línea de CSS agregando un comentario:

.widget { display: none !important; /* stylelint-disable-line declaration-no-important */}

O podemos desactivar stylelint para una parte de CSS:

/* stylelint-disable */.third-party-code {}/* stylelint-enable */

Uso

Stylelint se puede utilizar de muchas maneras : en la línea de comandos, en una herramienta de compilación (como Gulp, Grunt o Webpack), en un editor de código o como un gancho de confirmación previa de Git para cambios por etapas en el repositorio de Git. Me centraré aquí en dos formas.

Línea de comando

Usar la línea de comando es útil cuando deseas eliminar un proyecto que no tiene stylelint o deseas usar stylelint en un script npm.

Instale stylelint globalmente:

npm install stylelint -g

Luego, estará disponible en todas partes de tu terminal:

stylelint "styles/**/*.css"

Este comando eliminará todos los archivos CSS en el stylesdirectorio y cualquiera de sus subdirectorios.

Para eliminar archivos SCSS o SugarSS, agregue la syntaxopción:

stylelint "styles/*.scss" --syntax scss

El archivo de configuración se puede especificar explícitamente:

stylelint "styles/*.css" --config bar/myStylelintConfig.json

Si no se especifica explícitamente, stylelint buscará un .stylelintrcarchivo en el directorio de trabajo actual.

Trago

Para usar stylelint con Gulp, utilícelo como complemento PostCSS. Necesitará instalar los siguientes paquetes:

npm install gulp-postcss stylelint postcss-reporter --save-dev

gulp-postcss es un ejecutor para todos los complementos de PostCSS, y postcss-reporter genera errores y advertencias mucho mejores desde stylelint.

var postcss = require('gulp-postcss');var reporter = require('postcss-reporter');var stylelint = require('stylelint');gulp.task('lint:css', function() { return gulp.src('src/**/*.css') .pipe(postcss([ stylelint({ /* options */ }), reporter({ clearMessages: true }) ]));});

La salida sería así:

Para crear una hoja de estilo que no sea CSS, necesitarás instalar la sintaxis adecuada. Por ejemplo, para lint SCSS, necesitaríamos instalar postcss-scss :

npm install postcss-scss --savedev

Luego, configúrelo gulp-postcsspara usar esta sintaxis:

var postcss = require('gulp-postcss');var reporter = require('postcss-reporter');var stylelint = require('stylelint');var scss = require("postcss-scss");gulp.task('lint:css', function() { return gulp.src('src/**/*.scss') .pipe(postcss( [ stylelint({ /* options */ }), reporter({ clearMessages: true }) ], { syntax: scss } ));});

Puede especificar el archivo de configuración explícitamente; de lo contrario, stylelint buscará .stylelintrc.

Conclusión

Stylelint es un potente linter de hojas de estilo. Aporta claridad al código y le evita errores. Es útil para todos: desarrolladores individuales, equipos y mantenedores de código abierto. Una vez que comiences a usarlo, no escucharás más comentarios como "Olvidaste agregar un espacio aquí" o "Olvidaste eliminarlo allí". Feliz desarrollo y que tengas una revisión pacífica del código.

Otras lecturas

• Por qué es importante el estilo de codificación
• 7 principios de código CSS limpio y optimizado
• ESLint: el Linter JavaScript de próxima generación
• Una introducción a PostCSS

(rb, ml, al, il, mrn)Explora más en

• Codificación
• Herramientas
• javascript
• Técnicas

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Stylelint: la hoja de estilo Linter que siempre quisimos

Por qué es importante la pelusaEstilolintNormasComplementosArchivos de configuraciónUsoConclusiónTaller de diseño conductual, con Susan y Guthrie Weinschen

programar

es

https://aprendeprogramando.es/static/images/programar-stylelint-la-hoja-de-estilo-linter-que-siempre-quisimos-892-0.jpg

2025-01-14

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente