Vår erfaring å bytte fra mindre til Sass

Det er skrevet mye om å bytte fra vanilje CSS til en CSS forprosessor, og med god grunn - forprosessorer legger til kraft og kontroll vi ikke kan få i nettleseren alene. Fra artikler som hyller dyderne til en forprosessor til mer teknisk lesning som Etsys detaljerte ' Overgang til SCSS på skala , ”Jeg føler at jeg har fortært dem alle.

På HASHTAGS , vi gjorde noe som ikke har blitt skrevet om nesten like mye - å bytte fra en forprosessor til en annen. Tidlig vedtok Sprout Mindre ; vi tok beslutningen sent i fjor om å bytte til SCSS, den CSS-lignende syntaksen til Sass . Vi tok oss god tid for å sikre at overgangen var jevn, og opplevelsen fremhevet noen dype forskjeller mellom Less og Sass.

Hvorfor?

Før vi kommer til det vi lærte, bør ditt første spørsmål - et legitimt spørsmål - være: 'Hvorfor bry seg?' Vi har allerede hatt fordeler av variabler og mixins, @import og fargefunksjoner. Gjerne, Sass har en rekke funksjoner Mindre mangler, for eksempel kart og funksjoner , men vi kom så langt uten dem.

To hovedårsaker til å bytte skiller seg ut:

Samfunnet: Søk i github for lib-utvidelse: scss, søk deretter etter lib-utvidelse: mindre. I skrivende stund er resultatene klare: 120 234 SCSS-filer, 29 449 færre filer. Switching gir tilgang til et bredere utvalg av gode ideer og et større basseng med åpen kildekode for å svømme. Selv det populære Bootstrap-biblioteket, en av grunnene til at Less har holdt seg levedyktig, har kunngjort det bytter til SCSS .
Hastighet: Libsass bergarter. Byggetiden for stilene våre forbedret seg med over 500%. Mens Libsass ennå ikke har fått tak i den nyeste versjonen av Sass-spesifikasjonen, føler vi ikke at vi mangler noe.

Hvordan?

Vår kompilerte CSS har nesten 19.000 utvalgere. Etter byttet måtte den kompilerte CSS være nesten identisk; vi måtte sørge for at denne overgangen var usynlig for kundene våre. Og hva med funksjoner som pågår? Våre nylig komponere oppdatering endret 3,837 linjer med stiler - hvordan kunne teamet trygt bytte mellomstrøm?

Vi vurderte tre alternativer:

Kompiler alt til CSS først. Det er den eneste måten å sikre med 100% nøyaktighet at brukerne våre fikk de samme stilene og å trekke av bryteren på en dag. Ideen om en ren pause er alltid fristende, men ny kode er ikke alltid bedre kode . Selv med verktøy som f.eks sass-konvertere og css2kompass , den tiden vi ville bruke ombygging, ville oppveie andre muligheter.
Skriv bare nye stiler i SCSS. Vi vurderte å tegne en strek i sanden— Mindre er gammelt og busted; Sass er den nye heten . Til slutt avviste vi denne oppfatningen. Så mye ville være å tjene på å bytte umiddelbart, og ingen ønsket å opprettholde paritet mellom to sett med mixins og variabler.
Konverter alle våre Less-filer til SCSS og fikse det som går i stykker. Stilt overfor enten å kaste ut historien eller legge til en ny byggeoppgave å vedlikeholde, satte vi i gang med å konvertere alt.

Rengjøringshus

SCSS er ikke så forskjellig fra Less, er det? “ Konvertering fra mindre til Sass ”Deler en serie med regex-søk for å endre de mest åpenbare syntaksforskjellene, for eksempel .awesome-mixin () vs @mixin awesome-mixin (). Disse regex-søkene er rullet inn mindre2sass , som vi kjørte gjennom alle filene våre.

Hvis det var så enkelt, ville det virkelig ikke være mye å blogge om. Noen få dvelende henvendelser til less2sass-skriptet understreker noen av oversiktene, for eksempel strenginterpolasjonsforskjeller . Mer utfordrende var byggfeilene vi opplevde etter konverteringen, som markerte forskjeller større enn en enkel regex kunne løse. For å være ærlig fant vi også noe dårlig CSS.

Vi tok disse byggfeilene og laget en liste over hva vi trengte å fikse, og vi visste at vi kunne fikse det meste før vi konverterte stilene. Vi bestemte oss for å rydde opp i Less-filene våre før vi konverterte.

Fixin ’Mixins

Vi startet med forskjellen mellom hvordan Less og Sass håndterer conditionals. Her er en enkel gradientblanding vi hadde:

Sass tilbyr en enkel @ if… @ annet struktur, mens mixin vår brukte det Less kaller a mixin vakt . Når det gjelder vår gradientblanding, brukte vi den til å bytte fra leverandør-prefiks utkast syntaks til W3C syntaks. Vi visste at vi måtte skrive om denne blandingen.

Så stoppet vi og tok en lang titt på alle våre mixins. De fleste av dem la til forhandlerprefikser og løste forskjeller i nettleseren, for eksempel gradientmiksingen ovenfor. Tast inn Autofrefixer , et verktøy som analyserer CSS og bruker leverandørprefikser basert på en liste over støttede nettlesere. Ved å legge Autoprefixer til bygningen vår, eliminerte vi ni mixins. Som en bonus fjerner Autoprefixer unødvendige leverandørprefikser, som hjalp oss med å identifisere noen støvete hjørner i CSS og produsere mindre kompilerte filer.

En god lærdom fra vår erfaring her: Ikke kast bort tiden på å konvertere eller omgjøre det du kan slette.

En annen blandingsforskjell verdt å merke seg: Mindre anbefaler å skille parametere med semikolon . Bare noen få hadde blitt skrevet på denne måten, men de måtte alle endres, i mixin-definisjonene og hvor de ble brukt. Heldigvis støtter Less både semikolon og komma, så vi kan gjøre denne endringen før konverteringstrinnet.

0055 nummer

Ampersand misbruk

Etter å ha adressert mixins, vendte vi oppmerksomheten mot en annen kilde til byggfeil: ampersands . Det er en av de mektigste operatørene i både Sass og Less, og de fungerer veldig likt. Bortsett fra når de ikke gjør det. Og så fungerer de veldig annerledes.

For eksempel, med 19 000 velgere, kan du forestille deg at vi støter på spesifisitetsproblemer, ofte raskt løst som sådan:

Mindre produserer h1.modal-header som man skulle mistenke, men Sass kveler. Vi prøvde å fikse det med:

Fungerer bra med Ruby Sass, men når dette skrives, Libsass støtter ennå ikke denne bruken . Vi vurderte ikke engang, i dette tilfellet, å bytte til Ruby Sass. Vi skrev i stedet ut h1.modal-header utenfor .modal. Vi vet at dette er en indikasjon på et problem, så ved å trekke velgeren ut av omfanget og ringe den ut med en kommentar, kan vi lettere identifisere disse problemene i koden vår.

Det ble verre når et ampersand ble brukt på denne måten i en mixin. Her er et utdrag av en Less-mix vi hadde for knapper:

Igjen, @ at-root-direktivet kunne ikke hjelpe oss i Libsass. I dette tilfellet måtte vi se på årsaken til spesifisitetsoverstyringen og løse den. (Den gode nyheten er at vi fikset det ved å slette tre altfor spesifikke stiler andre steder.)

En annen forskjell mellom mindre og Sass-tegn var faktisk nyttig:

Vår forventning var .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Imidlertid behandler Less ampersand med mer rekursjon og kompileres således:

På intet tidspunkt brukte vi - eller ville vi - en avmerkingsboks-widget for en alternativknapp. Heldigvis løste Sass faktisk et problem vi ikke visste om fordi vi ikke så på vår kompilerte CSS.

Leksjon: Se på den kompilerte CSS-en ofte - ellers vet du ikke hva brukerne dine laster ned.

Sammenligning av resultatene

Oppdateringene for å fikse og fjerne mixins, løse ampersandavvik og adressere noen andre biter som ikke skulle konverteres rent, skjedde på tvers av syv forpliktelser i løpet av en måned. Det føltes bra å rengjøre huset og identifisere fremtidige refaktoriseringsmuligheter.

Likevel spiller det ingen rolle hvordan kildekoden vår ser ut; det er det som blir levert til brukerne våre som teller. Vi vurderte å generere AST-er for å sammenligne vår kompilerte CSS. Etter litt forskning og eksperimentering ble det klart at alt vi trengte var en måte å vite om veldig lite hadde endret seg i den kompilerte CSS. Derfor vil gode gammeldagse forskjeller være tilstrekkelig - jo mindre diff, jo bedre. Hver trekkforespørsel kom med en forskjell fra før og etter resultatene av mindre kompilering. Xcode utviklerverktøyet FileMerge var veldig nyttig å sammenligne resultatene side om side. Hvis vi så noe vi ikke forventet, gikk vi tilbake for å undersøke det.

Vi holdt fast ved FileMerge og diffs når vi gikk på regex-finn-og-erstatt stampede og faktisk konverterte filene til SCSS. Resultatene som ble samlet av to forskjellige forprosessorer, gjorde imidlertid at diffene var ubrukelige på grunn av forskjeller i tabbing og brakettplassering. Vi la til et ekstra trinn for å normalisere formatet til før og etter CSS med et enkelt nodeskript . Den miniserer CSS, og forskjønner den deretter. Kunne ikke være enklere.

Normalisering av formateringen hjalp sterkt, men det gikk fortsatt to faste dager med gjennomgang å kjenne gjennom diff. En givende prosess, men vanskelig. Vi tviler på at en tilpasset AST-løsning ville ha bidratt til å øke hastigheten på gjennomgangen. Alle forskjeller måtte løses.

Men forskjellene var små. Velger i litt annen rekkefølge, desimalavrunding og til og med små forskjeller i resultatene av fargefunksjoner. Hver forskjell ble sjekket nøye før vi presset vår Sassed-up CSS i produksjon.

Hva blir det neste

Når det var slått sammen, stoppet pågående arbeid nesten ikke. Mindre filer som fortsatt er under utvikling var enkle å konvertere, takket være alt forberedelsesarbeidet som ble gjort på forhånd. Alle var i gang om to dager. Selv det nydesignede Compose-teamet var i stand til å gå tilbake til SCSS på få timer. Å planlegge fremover og rydde opp i eksisterende stiler før du drar i bryteren, gjorde hele forskjellen.

Nå fortsetter vi med å identifisere mønstre, bryter opp store CSS-filer i moduler, kontrollerer CSS i produksjon for ubrukte velgere og bruker mer tid på verktøy for å sammenligne AST-er eller annen analysert representasjon av CSS-en. Nevnte jeg at vi har nesten 19 000 CSS-velgere? Vi er på det - men det er en annen artikkel helt.

Del Med Vennene Dine: