Parcelista Viteen: Tarina 100K LOC siirtymästä
Olemme siirtäneet kolme frontend-projektiamme Parcelista Viteen, ja prosessi oli... sujuva.
Olemme siirtäneet kolme frontend-projektiamme Parcelista Viteen, ja prosessi oli... sujuva.
Meillä on kolme pääasiallista frontend-projektia Logtossa: kirjautumiskokemus, Console ja live-esikatselu. Nämä projektit ovat kaikki TypeScriptillä, Reactilla ja SASS-moduuleilla; yhteensä niissä on noin 100 000 koodiriviä.
Rakastimme Parcelia sen yksinkertaisuuden ja nolla-asetuksen vuoksi. Muistan vieläkin päivän, jolloin hämmästyin siitä, kuinka helppoa oli perustaa uusi projekti Parcelilla. Voit vain suorittaa parcel index.html ja boom, kaikki tarvittavat riippuvuudet asennetaan ja projekti toimii. Jos olet "kokeneempi" kehittäjä, saatat tuntea samoin verratessasi sitä vanhoihin päiviin Gul-pilla ja Webpackilla. Parcel on kuin taikasauva.
Parcelin yksinkertaisuus oli pääsyy siihen, miksi pysyttäydyimme siinä niin pitkään, vaikka se saattoi olla joskus oikukas. Esimerkiksi:
Miksi päätimme siirtyä muuhun?
Joku jopa avasi keskustelun kysyäkseen onko Parcel kuollut. Virallinen vastaus on että ei, Parcel on yhä elossa, mutta se on tilassa jossa "meillä on käynnissä suuri refaktori eikä aikaa pienille julkaisuille". Meille se on kuin "ankan kuolema": viimeisin versio, jota voimme käyttää, on yli vuoden takainen, emmekä tiedä milloin seuraava versio julkaistaan. Se näyttää kuolleelta, se käyttäytyy kuin kuollut, joten se on kuollut meille.

Tunsimme Viten Vitestistä. Useita kuukausia sitten olimme väsyneitä Jestin ESM-tukeen (testauksessa) ja halusimme kokeilla jotain uutta. Vitest voitti sydämemme natiivilla ESM-tuellaan ja Jest-yhteensopivuudellaan. Sillä on loistava kehittäjäkokemus, ja se on Viten voimanlähde.
Sinulla saattaa olla erilaiset asetukset projektissasi, mutta yleensä löydät korvaavia plugineja, kun Vite-ekosysteemi kukoistaa. Tässä ovat asetuksemme siirtymähetkellä:
Aloitimme siirtymän luomalla uuden Vite-projektin ja leikkimällä sillä nähdäksemme, miten se toimii. Prosessi oli sujuva ja varsinainen siirtymä kesti vain muutaman päivän.
Vite tukee valmiiksi monorepoja, ESM:ää, TypeScriptiä, Reactia ja SASS:ia. Meidän tarvitsi vain asentaa tarvittavat pluginit ja konfiguraatiot saadaksemme sen toimimaan.
Vite tukee valmiiksi polkualiasia, esimerkiksi tsconfig.json-tiedostossamme:
Meidän tarvitsi vain lisätä sama resoluutio vite.config.ts-tiedostoossa:
Huomaa, että korvauspolun tulisi olla absoluuttinen polku, vaikka se on suhteellinen projektin juureen nähden. Vaihtoehtoisesti voit käyttää vite-tsconfig-paths pluginia lukeaksesi polkualiasit tsconfig.json-tiedostosta.
Vaikka Vite tukee valmiiksi HMR:ää, se vaatii pluginin asentamisen React Fast Refreshin ottamiseksi käyttöön. Käytimme @vitejs/plugin-react-pluginia, joka on Vite-tiimin tarjoama ja sisältää loistavan tuen React-ominaisuuksille, kuten Fast Refresh:
Käytämme vite-plugin-svgr-pluginia muuntaaksemme SVG:t React-komponenteiksi. Se on niin yksinkertaista kuin pluginin lisääminen Vite-konfiguraatioon:
Emme kuitenkaan määrittäneet, millä ehdolla SVG:t tulisi muuntaa React-komponenteiksi, joten kaikki tuonnit muunnettiin. Plugin tarjoaa paremman oletuskonfiguraation: muunna vain SVG:t, jotka tuodaan .svg?react-laajennuksella. Päivitimme tuontimme vastaavasti.
Vaikka Vite tukee valmiiksi SASS-moduuleita, on yksi asia, josta meidän on huolehdittava: kuinka luokkien nimet muotoillaan. Se voi olla vaivalloista käyttäjille ja integraatiotesteillemme, jos luokkien nimet eivät ole yhdenmukaisesti muotoiltuja. Yksinkertainen määritys vite.config.ts-tiedostossa voi ratkaista ongelman:
Muuten, Parcel ja Vite käyttävät erilaisia makuja tuontia varten SASS-tiedostoissa:
* as-syntaksi toimii kuitenkin Vitessä, mutta se aiheuttaa modulaaristen luokkien nimien menetyksen, kun käytät dynaamisia avaimia tietorakenteen styles objektiin. Esimerkiksi:
Koska Vite käyttää Rollupia taustalla, voimme käyttää virallista @mdx-js/rollup-pluginia tukemaan MDX:ää sekä sen plugineja. Määritys näyttää tältä:
remarkGfm-plugini tukee GitHub Flavored Markdownia, ja rehypeMdxCodeProps-plugini välittää rekvisiitat MDX-tiedostojen koodilohkoihin kuten Docusaurus tekee.
Haluaisimme käyttää Mermaid-kaavioita MDX-tiedostoissamme muiden ohjelmointikielten tavoin. Käytön pitäisi olla yhtä yksinkertaista kuin muiden koodilohkojen:
Pitäisi näyttää tältä:
Koska sovelluksemme tukee valo- ja tummateemoja, koodasimme hieman saadaksemme Mermaid-kaaviot toimimaan tummalla teemalla. React-komponentti on luotu:
useTheme on räätälöity hook, joka hakee nykyisen teeman kontekstista. mermaid-kirjasto tuodaan asynkronisesti latauskokoon pienentämiseksi alkuperäisessä sivulatauksessa.
MDX-tiedoston koodilohkoa varten meillä on yhtenäinen komponentti työn suorittamiseksi:
Lopuksi määrittelimme MDX-tarjoajan seuraavasti:
Tämä ei ole Vite-spesifi asia, mutta se on silti mainitsemisen arvoinen, sillä päivitimme sivumme käyttämään latauksen viivästystä siirtymän aikana, eikä mikään rikkonut sen jälkeen.
Reactin sisäänrakennettu React.lazy-funktio viivästettyjen komponenttien lataamiseksi kuitenkin saattaa aiheuttaa joitain ongelmia nopean iteroinnin aikana. Loimme pienen kirjaston nimeltä react-safe-lazy ongelmien ratkaisemiseksi. Se on pudotusvaihtoehto React.lazylle, ja yksityiskohtainen selitys löytyy tästä blogikirjoituksesta.
On olemassa kätevä plugin nimeltä vite-plugin-compression pakattujen resurssien tuottamiseksi. Se tukee sekä gzip- että brotli-pakkausta. Määritys on yksinkertainen:
Yksi hieno ominaisuus Viteessa (tai taustalla olevassa Rollupissa) on manuaaliset kontit. Vaikka React.lazy käytetään komponenttien laiskaan lataamiseen, meillä on enemmän hallintaa kontteihin määrittämällä manuaaliset kontit päättääksemme, mitkä komponentit tai moduulit pitäisi niputtaa yhteen.
Esimerkiksi voimme ensin käyttää vite-bundle-visualizer analysoidaksemme paketin kokoa ja riippuvuuksia. Sitten voimme kirjoittaa asianmukaisen funktion lohkojen jakamiseksi:
Toisin kuin tuotantorakenne, Vite EI niputa lähdekoodiasi kehitystilassa (mukaan lukien linkitetyt riippuvuudet samassa monorepossa) ja käsittelee jokaista moduulia tiedostona. Meille selain lataa satoja moduuleja ensimmäisellä kerralla, mikä näyttää hullulta, mutta se on oikeastaan fine useimmissa tapauksissa. Voit nähdä keskustelun tässä.
Jos tämä on sinulle ongelma, vaihtoehtoinen mutta epätäydellinen ratkaisu on listata linkitetyt riippuvuudet optimizeDeps-vaihtoehtoon vite.config.ts-tiedostoossa:
Tämä "ennakkoniputtaa" linkitetyt riippuvuudet ja nopeuttaa kehityspalvelinta. Haittapuoli on, että HMR ei välttämättä toimi odotetusti linkitetyillä riippuvuuksilla.
Lisäksi käytämme välityspalvelinta, joka palvelee staattisia tiedostoja tuotannossa ja välittää pyynnöt Vite-palvelimeen kehityksessä. Meillä on joitain määritettyjä portteja konfliktien välttämiseksi, ja se on myös helppo määrittää vite.config.ts-tiedostoossa:
Toisin kuin Parcel, Vite käyttää modernia lähestymistapaa ympäristömuuttujien käsittelyyn käyttämällä import.meta.env. Se lataa automaattisesti .env-tiedostot ja korvaa muuttujat koodissa. Se vaatii kuitenkin, että kaikilla ympäristömuuttujilla on VITE_-etuliite (määritettävissä).
Kun käytimme Parcelia, se yksinkertaisesti korvasi process.env-muuttujat ilman etuliitteen tarkistamista. Joten olemme keksineet kiertotavan käyttämällä define-kenttää helpottamaan siirtymää:
Tämä sallii meidän lisätä vähitellen etuliitteen ympäristömuuttujille ja poistaa define-kentän.
Siinä se! Olemme onnistuneesti siirtäneet kolme frontend-projektiamme Parcelista Viteen, ja toivomme, että tämä lyhyt tarina voi auttaa sinua omassa siirtymässäsi. Tässä miltä konfiguraatio näyttää lopussa: