Koondamine vs Webpack (JavaScripti komplekteerimine 2018. aastal)

Ehkki tööriistade standardid on JavaScripti maal hakanud stabiliseeruma, on töö jaoks sobiva tööriista osas siiski pisut segadust. See on pakkimise ja Webpacki mõnevõrra üksikasjalik võrdlus. Alustame nende vastavate konfiguratsioonifailide võrdlemist.

Seadistamine

rollup.config.js

webpack.config.js

Kiire erinevused, mida tuleb tähele panna:

Koondkomplektil on impordi / ekspordi jaoks sõlmede polütäidised, samas kui veebipakil seda pole

Koondkomplektil on suhteliste teede tugi, samas kui veebipakil seda pole, seega kasutame kas path.resolve või path.join

Ühendamine eeldab, et es2015 eelseadetes oleks moodulid valeks seatud, sest see töötleb mooduleid ES2015-na, kui see saab enne mooduli ümberpaigutamist ulatuse tõstmise võlu.

Võtame väga lihtsa näite:

some-file.js

index.js

Milline oleks teie eeldatav väljund sellest?

Vaieldamatult paistab see roll. Lihtsamate moodulite jaoks tagastab see väga tõhusalt muundatud minimaalse komplekti, samas kui Webpack sisaldab paketti palju magic ™ -i.

bundle.rollup.js - ~ 245 baiti

bundle.webpack.js - ~ 4108 baiti

Webpacki paketis toimub tegelik import umbes 100-real. Sellesse punkti liikudes näete, et mooduli tegelik kood on enamasti sama (allpool), suurim erinevus on see, et Webpacki komplektis on iga moodul mähitud funktsiooni, mida saab sisemiselt käivitada. Seetõttu peetakse Webpacki kimbud suuremate / keerukamate rakenduste jaoks turvalisemaks.

Suur osa jama eemaldatakse tootmisrežiimi ehitamisel ja kimpude suurusel.

Niisiis, kuidas öelda, milline neist sobib teile? Lähiajaloos on tavapärased tarkused olnud järgmised:

„Kasutage rakenduste jaoks veebipaketti ja raamatukogude koondandmeid“

Kuid seda on reeglina keerukam õigustada. Veebipaketi täiustused on tõesti pakkumise üldise efektiivsuse osas võrdsed ning pakkumine lisas hiljuti koodide jagamise (peamised funktsioonid, mis nende kahe vahel puuduvad).

Päriselu paralleelseks muutmiseks võrdleksin seda komplekteerimislahingut tootekujunduse teooriaga, mille nimi on “Kano mudel”. Kano mudelis öeldakse põhimõtteliselt, et „aja jooksul muutub veetlev innovatsioon teiseks põhivajaduseks”.

Võtke näiteks nool auto kütuse näidikul, et näidata, millisele küljele kütusepump tuleb suunata (joonis 1). Idee loomisel peeti seda suureks uuenduseks, kuid nüüd on see kasutajate seas lihtsalt ootus.

Joonis 1: kütusepaagi korgi külgmine näidik

Tegelike eristavate omaduste nägemiseks peame minema tagasi 2016. aasta metsikusse lääneossa.

Kokkuvõte (umbes 2016)

Plussid:

  • Puude raputamine (reaalajas koodi kaasamine / surnud koodi kõrvaldamine)
  • esnext: peamine kanne paketis.json, et importida es2015 + (ümbernimetatud mooduliks)
  • Reguleerimisala tõstmine
  • Lihtne API

Miinused:

  • Piiratud tugi alternatiivse failitüübi laadimisel (css, pildid jne)
  • Koodi ei poolita

Webpack (umbes 2016)

Plussid:

  • CSS / HTML / pildi laadimise täiustatud tugi
  • Koodide poolitamine
  • Kuum mooduli asendamine ülikiirete arenduste jaoks

Miinused:

  • Puud ei raputa
  • Reguleerimisala ei tõsteta
  • ES2015 + moodulite algne tugi puudub
  • Keeruline API

Pärast seda on palju muutunud (ülaltoodud pole täielik loetelu ja mõlemal raamatukogul on täiendavaid plusse ja miinuseid, mida ma ei osanud ehk loetleda) ning mõlemad raamatukogud on võtnud üksteiselt näpunäiteid. Samuti on kasvanud mõlemat raamatukogu ümbritsev kogukond, mis on aidanud kiirendada uudsete funktsioonide rakendamist.

Kokkuvõte (nüüd) - mis on muutunud?

  • Rikkalik ökosüsteem pistikprogrammidele faili laadimise / arendusserverite jaoks
  • Koodide jagamine (lisatud 8. veebruar 2018 pärast kaheaastast ootamist! )

Webpack (nüüd) - Mis on muutunud?

  • Puude raputamine ja ES2015 + mooduli tugi (lisatud Webpack 2-s)
  • Ulatuse tõstmine (lisatud Webpack 3-s)
  • Toetus järgmisele: peamine / moodul

Minu arvates peaksite ikkagi eelistama raamatukogude jaoks koondandmeid, kuid võimalus kasutada suurte rakenduste korral koondamisruumi on palju realistlikum. Üks on kindel, et nii Webpack kui ka koondandmed on siin selleks, et jääda. Ma ütleksin, et nende kahe raamatukogu püsivuse peamine põhjus on hämmastavad sisemised meeskonnad ja lõputud pingutused nende ülalpidamiseks ning probleemidele ja StackOverflow küsimustele vastamisele.

Kahe raamatukogu sisemiste materjalide üksikasjalikumaks võrdlemiseks on Rich Harrisel (koondaruumi looja) siin suurepärane kirjutada.

BONUS: Väljakutsuja läheneb

Pakk on uus ja huvitav komplekteerija, millel on palju samu funktsioone nagu koondaval ja Webpackil (nt koodide jagamine ja vara laadimine), kuid suur funktsioon, mida see tunneb, on nullkonfiguratsiooniga tõusta ja minna komplekteerimise lahendus. Kui oleksite 2015. aastal kogukonnas ringi liikunud, mäletaksite kurikuulsat ajaveebi postitust „JavaScripti väsimus“. Üks autor tõdeb, et meie tööriistade tegemine oli lihtsalt jama ja nii oligi. Maailm polnud otsustanud, milliseid tööriistu me peaksime kasutama, nii et suurem osa minu projektidest oli segu Gulpist, brauserima (koos babelifyga) ja alustamine polnud kunagi lihtne.

Paki puhul on müügiargumendiks see, et teil on index.html-fail, mis osutab JavaScripti sisestusele, ja saate lihtsalt käivitada paki index.html ning lasta teil hetkega töötada väljamõeldud deviserveriga. Ühtlasi väidab ta, et sellel on kiire villide tekkimise kiirus (kuigi nende võrdlustabel ei sisalda koondandmete võrdlust, nii et võin ainult oletada, et need on sarnased).

Kui Parcel osutab püsivust Webpackina / koondandmena, olen kindel, et näeme, et paljud nullkonfiguratsiooni funktsioonid mullivad nendes raamatukogudes pinnale.