Nuestra experiencia cambiando de Less a Sass

Se ha escrito mucho sobre el cambio de CSS vanilla a un preprocesador de CSS, y por una buena razón, los preprocesadores agregan potencia y control que no podemos obtener solo en el navegador. De artículos que ensalzar las virtudes de un preprocesador a lecturas más técnicas como la detallada de Etsy ' Transición a SCSS a escala , 'Siento que los he devorado a todos.

A HASHTAGS , hicimos algo sobre lo que no se ha escrito tanto: cambiar de un preprocesador a otro. Al principio, Sprout adoptó Menos ; Tomamos la decisión a fines del año pasado de cambiar a SCSS, la sintaxis similar a CSS de Hablar con descaro a . Nos tomamos nuestro tiempo para asegurarnos de que la transición fuera fluida y la experiencia destacó algunas diferencias profundas entre Less y Sass.

¿Por qué?

Antes de llegar a lo que aprendimos, su primera pregunta, una legítima, debería ser: '¿Por qué molestarse?' Ya nos beneficiamos de variables y mixins, @imports y funciones de color. Ciertamente, Sass tiene una serie de características de las que Less carece, como mapas y funciones , pero llegamos tan lejos sin ellos.

Se destacan dos razones principales para el cambio:

Comunidad: Busque en github la extensión lib: scss, luego busque la extensión lib: menos. Al momento de escribir estas líneas, los resultados son claros: 120.234 archivos SCSS, 29.449 archivos menos. Cambiar ofrece acceso a una gama más amplia de buenas ideas y una piscina de código abierto más grande para nadar. Incluso la popular biblioteca Bootstrap, una de las razones por las que Less sigue siendo viable, ha anunciado está cambiando a SCSS .
Velocidad: Libsass rocas. El tiempo de construcción de nuestros estilos mejoró en más de un 500%. Si bien Libsass aún no se ha puesto al día con la última versión de la especificación Sass, no creemos que nos falte nada.

¿Cómo?

Nuestro CSS compilado tiene casi 19.000 selectores. Después del cambio, ese CSS compilado tenía que ser casi idéntico; teníamos que asegurarnos de que esta transición fuera invisible para nuestros clientes. ¿Y qué hay de las funciones actualmente en curso? Nuestra actualización de redacción reciente cambió 3.837 líneas de estilos, ¿cómo podría ese equipo cambiar de manera segura a mitad de camino?

Consideramos tres opciones:

Primero compile todo en CSS. Es la única forma de garantizar con una precisión del 100% que nuestros usuarios obtenían los mismos estilos y de poder desconectar el interruptor en un día. La idea de una ruptura limpia siempre es tentadora, pero el nuevo código no siempre es mejor código . Incluso con herramientas como sass-convert y css2compass , el tiempo que dedicaríamos a la reconstrucción superaría con creces cualquier otra opción.
Escriba solo nuevos estilos en SCSS. Consideramos trazar una línea en la arena Menos es viejo y arruinado; Sass es el nuevo picor . Finalmente, rechazamos esta noción. Se ganaría mucho al cambiar de inmediato, y nadie quería mantener la paridad entre dos conjuntos de combinaciones y variables.
Convierta todos nuestros archivos Less a SCSS y corrija los fallos. Frente a tirar el historial o agregar otra tarea de compilación para mantener, nos dispusimos a convertir todo.

Limpiando la casa

SCSS no es tan diferente de Less, ¿verdad? ' Conversión de Less a Sass ”Comparte una serie de búsquedas de expresiones regulares para cambiar las diferencias de sintaxis más obvias, como .awesome-mixin () vs @mixin awesome-mixin (). Esas búsquedas de expresiones regulares se acumulan en less2sass , que revisamos todos nuestros archivos.

Sin embargo, si fuera tan fácil, no habría mucho sobre lo que bloguear. Algunas solicitudes de extracción persistentes al script less2sass enfatizan algunos de sus descuidos, como diferencias de interpolación de cadenas . Más desafiantes fueron los errores de compilación que encontramos después de la conversión, que resaltaron diferencias mayores que las que una simple expresión regular podría resolver. Para ser sincero, también encontramos algunos CSS malos.

Tomamos esos errores de compilación e hicimos una lista de lo que necesitábamos corregir, y sabíamos que podíamos corregir la mayor parte antes de convertir los estilos. Decidimos limpiar nuestros archivos Less antes de convertirlos.

Fixin ’Mixins

Comenzamos con la diferencia entre cómo Less y Sass manejan los condicionales. Aquí hay una mezcla de degradado simple que tuvimos:

Sass ofrece una estructura @ if… @ else simple, mientras que nuestro mixin empleó lo que Less llama guardia de mezcla . En el caso de nuestra mezcla de degradado, la usamos para cambiar de la sintaxis de borrador prefijada por el proveedor a la sintaxis W3C. Sabíamos que tendríamos que reescribir este mixin.

Luego, nos detuvimos y echamos un vistazo a todos nuestros mixins. La mayoría de ellos agregaron prefijos de proveedores y resolvieron diferencias de navegador, como la mezcla de degradado anterior. Ingresar Autoprefixer , una herramienta que analiza CSS y aplica prefijos de proveedores en función de una lista de navegadores compatibles. Al agregar Autoprefixer a nuestra compilación, eliminamos nueve mixins. Como beneficio adicional, Autoprefixer elimina los prefijos de proveedores innecesarios, lo que nos ayudó a identificar algunos rincones polvorientos en nuestro CSS y producir archivos compilados más pequeños.

Una buena lección de nuestra experiencia aquí: no pierda el tiempo convirtiendo o refactorizando lo que puede eliminar.

Otra diferencia de mixin que vale la pena señalar: Less recomienda separar los parámetros con punto y coma . Solo algunos se habían escrito de esta manera, pero todos debían cambiarse, en las definiciones mixtas y donde se aplicaban. Afortunadamente, Less admite punto y coma y comas, por lo que podríamos realizar este cambio antes del paso de conversión.

significado del número siete

Abuso de ampersand

Después de abordar los mixins, dirigimos nuestra atención a otra fuente de errores de compilación: símbolos de unión . Es uno de los operadores más poderosos tanto en Sass como en Less, y funcionan de manera muy similar. Excepto cuando no lo hacen. Y luego funcionan de manera muy diferente.

Por ejemplo, con 19.000 selectores, puede imaginar que nos encontramos con problemas de especificidad, que a menudo se resuelven rápidamente como tales:

Less produce h1.modal-header como uno sospecharía, pero Sass se ahoga. Intentamos arreglarlo con:

Funciona muy bien con Ruby Sass, pero al momento de escribir este artículo, Libsass aún no admite este uso . En este caso, ni siquiera consideramos cambiar a Ruby Sass. En su lugar, escribimos h1.modal-header fuera del alcance de .modal. Sabemos que esto es una indicación de un problema, por lo que al sacar el selector del alcance y llamarlo con un comentario, podemos identificar esos problemas en nuestro código más fácilmente.

Empeoró cuando se usó un ampersand de esta manera en un mixin. Aquí hay un extracto de una mezcla de Less que teníamos para botones:

Nuevamente, la directiva @ at-root no pudo ayudarnos en Libsass. En este caso, tuvimos que buscar la causa raíz de la anulación de especificidad y resolverla. (La buena noticia es que lo solucionamos eliminando tres estilos demasiado específicos en otros lugares).

Otra diferencia entre los símbolos de unión Less y Sass fue realmente útil:

Nuestra expectativa era .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Sin embargo, Less procesa el ampersand con más recursividad y lo compila así:

En ningún momento usamos, o usaríamos, un widget de casilla de verificación para un botón de opción. Afortunadamente, Sass resolvió un problema que no conocíamos porque no estábamos mirando nuestro CSS compilado.

Lección aprendida: mire su CSS compilado con frecuencia; de lo contrario, no sabrá qué están descargando sus usuarios.

Comparando los resultados

Las actualizaciones para corregir y eliminar mixins, resolver las discrepancias comerciales y abordar algunas otras partes que no se iban a convertir de forma limpia se produjeron en siete confirmaciones en el transcurso de un mes. Se sintió bien limpiar la casa e identificar futuras oportunidades de refactorización.

Sin embargo, no importa cómo se vea nuestro código fuente; lo que cuenta es lo que llega a nuestros usuarios. Consideramos generar AST para comparar nuestro CSS compilado. Después de algunas investigaciones y experimentación, quedó claro que todo lo que necesitábamos era una forma de saber si muy poco había cambiado en el CSS compilado. Por lo tanto, serían suficientes las diferencias a la antigua; cuanto menor sea la diferencia, mejor. Cada solicitud de extracción venía con una diferencia de los resultados anteriores y posteriores de la compilación Less. La herramienta de desarrollo de Xcode FileMerge fue muy útil para comparar los resultados uno al lado del otro. Si vimos algo que no esperábamos, volvíamos a investigar.

Nos quedamos con FileMerge y diffs una vez que comenzamos nuestra estampida de búsqueda y reemplazo de expresiones regulares y realmente convertimos los archivos a SCSS. Sin embargo, los resultados compilados por dos preprocesadores diferentes hicieron que nuestras diferencias fueran inútiles debido a las diferencias en la colocación de tabulaciones y corchetes. Agregamos un paso adicional para normalizar el formato del CSS antes y después con un script de nodo simple . Minimiza el CSS y luego lo embellece. No podría ser más sencillo.

Normalizar el formato ayudó mucho, pero revisar las diferencias tomó aproximadamente dos días completos de revisión. Un proceso gratificante pero arduo. Dudamos que una solución AST personalizada hubiera ayudado a acelerar la revisión. Debían abordarse todas las diferencias.

Pero las diferencias fueron menores. Selectores en un orden ligeramente diferente, redondeo decimal e incluso ligeras diferencias en los resultados de las funciones de color. Cada diferencia se verificó cuidadosamente antes de impulsar nuestro CSS Sassed-up en producción.

Que sigue

Una vez fusionados, el trabajo en curso apenas se estancó. Menos archivos aún en desarrollo fueron fáciles de convertir, gracias a todo el trabajo de preparación realizado con anticipación. Todo el mundo estaba listo y funcionando en unos dos días. Incluso el equipo de Compose rediseñado pudo regex su camino a SCSS en cuestión de horas. Planear con anticipación y limpiar los estilos existentes antes de presionar el interruptor hizo toda la diferencia.

Ahora estamos avanzando con la identificación de patrones, dividiendo archivos CSS grandes en módulos, auditando CSS en producción en busca de selectores no utilizados y dedicando más tiempo a las herramientas para comparar AST o alguna otra representación analizada de nuestro CSS. ¿Mencioné que tenemos casi 19,000 selectores CSS? Estamos en eso, pero ese es otro artículo completamente.

Compartir Con Tus Amigos: