Kas yra Rome ir kodėl apie jį verta žinoti
Jei dirbate su JavaScript ekosistema, tikriausiai žinote, kad projektų konfigūravimas gali virsti tikru galvos skausmu. ESLint, Prettier, Babel, Webpack – sąrašas tęsiasi ir tęsiasi. Kiekvienas įrankis turi savo konfigūracijos failus, priklausomybes ir keistenybes. O ką jei pasakyčiau, kad egzistuoja sprendimas, kuris siekia viską supaprastinti?
Rome – tai ambicinga iniciatyva, kuri bando pakeisti tai, kaip mes dirbame su JavaScript ir TypeScript projektais. Pagrindinė idėja paprasta: vienas įrankis, kuris pakeičia daugybę atskirų įrankių, ir viskas veikia iš karto be sudėtingos konfigūracijos.
Projektas gimė iš frustracijų, kurias patyrė Sebastian McKenzie – tas pats žmogus, kuris sukūrė Babel. Jis puikiai žinojo, kokie sudėtingi gali būti šiuolaikiniai JavaScript įrankiai, todėl nusprendė pradėti nuo nulio ir sukurti kažką fundamentaliai kitokio.
Ką Rome siūlo vietoj įprastų įrankių
Rome pozicionuoja save kaip „all-in-one” sprendimą. Tai reiškia, kad vienas įrankis atlieka kelių funkcijas:
Linteris – analizuoja kodą ir randa klaidas bei stilistines problemas. Tai, ką paprastai darytumėte su ESLint.
Formateris – automatiškai suformatuoja jūsų kodą pagal nustatytus standartus. Prettier alternatyva.
Bundleris – sujungia modulius į galutinį failą (ši funkcija vis dar kuriama).
Testeris – leidžia paleisti testus (taip pat dar vystoma funkcija).
Viskas parašyta Rust programavimo kalba, o tai reiškia, kad veikimo greitis yra itin aukštas. Palyginti su Node.js bazuotais įrankiais, skirtumas gali būti dešimteriopas ar net didesnis. Kai dirbi su dideliais projektais, tai tikrai jaučiasi.
Kaip pradėti naudoti Rome savo projekte
Įdiegimas yra paprastas kaip ir bet kurio kito npm paketo. Atidarykite terminalą ir įveskite:
npm install --save-dev rome
Arba jei naudojate yarn:
yarn add --dev rome
Ir štai čia prasideda magija – jums nereikia kurti jokių konfigūracijos failų. Rome veikia su protingais numatytaisiais nustatymais iš karto. Norite patikrinti savo kodą? Tiesiog paleiskite:
npx rome check .
Ši komanda patikrins visus failus dabartiniame kataloge ir praneš apie rastas problemas. Norite automatiškai suformatuoti kodą?
npx rome format --write .
Matote? Jokių .eslintrc, .prettierrc ar kitų konfigūracijos failų. Viskas veikia iš karto.
Konfigūracija, kai jos vis dėlto reikia
Žinoma, kartais numatytieji nustatymai netinka jūsų projektui. Gera žinia ta, kad Rome konfigūracija yra kur kas paprastesnė nei įprastų įrankių.
Sukurkite rome.json failą projekto šakniniame kataloge:
{
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
},
"formatter": {
"enabled": true,
"indentStyle": "space",
"indentSize": 2,
"lineWidth": 100
}
}
Tai jau sudėtingesnė konfigūracija, bet palyginti su tuo, ką reikia nustatyti ESLint ir Prettier kombinacijai, tai tikras malonumas. Viskas vienoje vietoje, aiški struktūra, jokių konfliktų tarp skirtingų įrankių.
Jei norite ignoruoti tam tikrus failus ar katalogus, galite tai padaryti taip:
{
"files": {
"ignore": ["dist/**", "node_modules/**", "*.min.js"]
}
}
Integracija su populiariausiomis redagavimo programomis
Rome komandos nariai supranta, kad daugelis kūrėjų nori matyti klaidas ir formatavimo pasiūlymus tiesiai savo kodo redaktoriuje. Todėl jie sukūrė plėtinius populiariausioms platformoms.
Visual Studio Code naudotojams yra oficialus Rome plėtinys. Įdiekite jį iš Extensions marketplace ieškodami „Rome”. Po įdiegimo jis automatiškai aptiks, ar jūsų projekte naudojamas Rome, ir pradės veikti.
Plėtinys rodo klaidas tiesiai kode su raudonomis pabraukimais, leidžia formatuoti failą išsaugant (format on save), ir net siūlo automatines pataisas kai kurioms problemoms.
Neovim ir kiti LSP palaikantys redaktoriai taip pat gali naudoti Rome per Language Server Protocol. Reikia tik sukonfigūruoti LSP klientą, kad jis naudotų Rome serverį.
Praktinis patarimas: jei dirbate komandoje, įsitikinkite, kad visi naudoja tuos pačius redaktoriaus nustatymus. Galite sukurti .vscode/settings.json failą su Rome nustatymais ir įtraukti jį į versijavimo sistemą.
Migracija iš esamų įrankių
Tikriausiai galvojate: „Skamba puikiai, bet aš jau turiu projektą su ESLint ir Prettier. Kaip pereiti prie Rome?”
Atsakymas priklauso nuo to, kiek sudėtingas jūsų projektas. Jei naudojate standartines ESLint ir Prettier konfigūracijas, migracija gali būti gana paprasta:
1. Pašalinkite ESLint ir Prettier priklausomybes iš package.json
2. Ištrinkite jų konfigūracijos failus
3. Įdiekite Rome
4. Paleiskite npx rome check . ir pažiūrėkite, kas nutinka
Tačiau jei turite daug custom taisyklių ar naudojate specifines ESLint plėtinių, situacija gali būti sudėtingesnė. Rome dar nepalaiko visų ESLint taisyklių, nors jų sąrašas nuolat auga.
Vienas iš būdų – palaipsniui migracijos strategija. Galite pradėti naudoti Rome naujuose failuose ar moduliuose, o senus palikti su ESLint. Tai leidžia pamažu pereiti prie naujo įrankio be didelio projekto sutrikdymo.
Realūs privalumai ir dabartiniai apribojimai
Pabandžius Rome keliuose projektuose, išryškėja tiek privalumai, tiek trūkumai.
Kas tikrai veikia gerai:
Greitis yra įspūdingas. Didelio projekto tikrinimas, kuris su ESLint užtrunka 30 sekundžių, su Rome gali užtrukti 3-5 sekundes. Tai keičia žaidimo taisykles, ypač jei linterį paleidžiate dažnai.
Paprastumas yra tikras. Nebereikia galvoti, ar Prettier ir ESLint nesikonfliktuos, ar teisingai sukonfigūravote eslint-config-prettier. Viskas tiesiog veikia.
Klaidų pranešimai yra aiškesni nei daugelio kitų įrankių. Rome stengiasi ne tik pasakyti, kas negerai, bet ir paaiškinti, kodėl tai problema ir kaip ją išspręsti.
Kur dar reikia tobulėti:
Taisyklių skaičius vis dar mažesnis nei ESLint. Jei jūsų projektas remiasi specifinėmis ESLint taisyklėmis ar plėtiniais (pavyzdžiui, React ar Vue specifinėmis taisyklėmis), gali tekti palaukti.
Ekosistema dar jauna. Tai reiškia, kad ne visos integracijos veikia idealiai, dokumentacija kai kur trūkstama detalių, o community palaikymas nėra toks platus kaip ESLint atveju.
Bundlerio ir testerio funkcijos dar nebaigtos. Tai reiškia, kad visiškai pakeisti Webpack ar Jest dar negalėsite.
Ateities perspektyvos ir ką verta stebėti
Rome projektas yra aktyviai vystomas, ir jo ateitis atrodo šviesi. Kūrėjai turi aiškią viziją ir nuosekliai dirba link jos įgyvendinimo.
Vienas įdomiausių dalykų – tai kaip Rome bendruomenė auga. Vis daugiau kūrėjų prisideda prie projekto, siūlo pataisymus, praneša apie klaidas ir kuria integracijas su kitais įrankiais.
Taip pat verta paminėti, kad Rome komanda aktyviai bendradarbiauja su kitų įrankių kūrėjais. Jie nesiekia tiesiog „nukopijuoti” ESLint ar Prettier – jie bando sukurti kažką geresnio, mokydamiesi iš ankstesnių įrankių klaidų.
Jei planuojate naują projektą, Rome tikrai verta išbandyti. Net jei galiausiai nuspręsite grįžti prie įprastų įrankių, patirtis su kitokiu požiūriu į JavaScript tooling bus naudinga.
Esamiems projektams rekomenduočiau palaukti, kol Rome pasiekia stabilesnę versiją ir išplečia taisyklių sąrašą. Tačiau jei jūsų projektas nėra labai sudėtingas ir nenaudojate daug specifinių ESLint plėtinių, galite drąsiai eksperimentuoti.
Kodėl paprastumas yra nauja kokybė
Grįžtant prie pagrindinės Rome idėjos – konfigūracijos nebuvimo – tai tikrai gaivinantis požiūris šiuolaikinėje JavaScript ekosistemoje. Per pastaruosius metus įrankiai tapo tokie sudėtingi, kad kartais jaučiasi, jog daugiau laiko praleidžiame konfigūruodami nei rašydami kodą.
Rome primena, kad įrankiai turėtų padėti, o ne trukdyti. Kad numatytieji nustatymai gali būti pakankamai geri daugumai atvejų. Kad greitis ir paprastumas yra svarbūs.
Ar Rome pakeis visus kitus įrankius? Greičiausiai ne greitai. Bet jis jau dabar verčia kitus įrankių kūrėjus permąstyti savo požiūrį. ESLint komanda dirba prie greičio patobulinimų, Prettier galvoja apie paprastesnę konfigūraciją. Tai gera konkurencija, kuri naudinga visiems.
Tad jei esate pavargę nuo konfigūracijos failų džiunglių, jei norite, kad jūsų įrankiai veiktų greitai ir be problemų, Rome tikrai vertas jūsų dėmesio. Išbandykite jį mažame projekte, pažiūrėkite, kaip jaučiasi. Galbūt tai bus būtent tas įrankis, kurio ieškojote.
