Iepazīstinām ar Packem: ļoti ātrs eksperimentāls komplekts, kas rakstīts Rust

Packem ir eksperimentāls iepriekš kompilēts JavaScript moduļu pakete, kas galvenokārt ieviesta Rust. Tas var arī apstrādāt dažādus citus failu tipus, piemēram, YAML / TOML, fragmentu ēnotāju failus un daudz ko citu. Lai ātri sāktu, apmeklējiet vietni vai GitHub lapu.

Packem atrisina moduļa atkarības un rehidratē tās moduļa diagrammā - plakanā sarakstā, kas satur moduļu saskarnes, kas būtībā ir atsauces uz maināmām datu struktūrām atmiņā, kas satur kaudzi , kas moduļa diagrammā satur īpašus moduļa metadatus.

Lielākā daļa biznesa loģikas tiek abstrahēta Rust, izmantojot FFI saistījumus, lai iespējotu zema līmeņa mijiedarbību starp abiem galiem. Rusty binārie faili ir pieejami kā iepriekš kompilēti Node C / C ++ papildinājumi Packem repo. Uz mākoņa balstītu CI izmanto, lai palaistu dažus skriptus ar pirmsšifrēšanas instalācijām, nodrošinot OS specifiskus bināros failus ar atbalstu jaunākajām mezglu versijām (8, 9, 10).

Šis Packem kodola slānis tiek saukts par loģisko kontekstu (LC) . Visas pārējās operācijas, kas nav skaidri noteiktas kā prioritātes, tiek regresētas mezgla vispārējā izpildlaikā, kas Packem izteiksmē ir Runtime Context (RC) . Vairāk par kontekstiem lasiet šeit.

Teorētiski moduļa grafiks tiek turēts līdzens, lai izvairītos no izplatītām kļūmēm, kas novestu pie nevajadzīgiem šķērsošanas gadījumiem, ja koks tiktu izmantots vietā. Tas ļauj RC sekot tādiem gadījumiem kā dziļas cirkulāras atkarības vai smagi ligzdotas dinamiskas importēšanas (koda sadalīšana), cita starpā, ar minimālu ietekmi uz darbību vai pēc iespējas mazākām sekām.

Sīkāka informācija ir atrodama Packem vietnē README.md.

Man ir bijusi šī ideja prātā, bet es nekad neesmu plānojis to realizēt, līdz es apvienoju spēkus ar Saddamu M. Man patiešām ir bijusi interese redzēt moduļu apvienošanu kā koncepciju, kuru droši var iemācīties, saprast un īstenot ikviens. Tas, ka cilvēki cīnījās ar konfigurācijām, dokumentāciju un spraudņiem, bija ārkārtīgi šausminoši, un es gribētu izmantot iespēju to mainīt. Ar Tevi. Ar Packem.

Ātra vēsture

Es pavadīju kādu laiku, lai iztukšotu lielāko daļu kopu, kas rakstīti vidē, kas nav JavaScript. Es uzzināju, ka lielākā daļa no viņiem aizmirsa, ka viņiem vajadzētu būt saiņotājam, nevis C / C ++ bibliotēkai no 19. gadsimta tumšajiem.

Tas, ko es gribēju, bija saiņotājs, kas lielāko daļu smagā pacelšanas veic lietotājam tuvā metāla valodā, neprasot nekādu mijiedarbību ar tā iekšējiem elementiem. Tad es atradu Rūsu. Gudra un kodolīga sistēmu valoda, kas parāda dažas slavējamas funkcijas, piemēram, bezbailīgu vienlaicīguma modeli, tipa drošību un daudz ko citu! Es sagaidītu tikpat daudz no C / C ++ izmantošanas, bet es labāk gribētu palikt pie Rust, jo tas ir diezgan vienkārši atmiņas pārvaldībā.

Kāpēc vēl viens saišķis?

Tātad, ko šeit ņemt? Kāpēc mums ir nepieciešams vēl viens būvēšanas rīks, jo mums jau ir pārsteidzoši rīki, piemēram, webpack, Parcel, Rollup utt.? Es ņemšu jūs kopā ar dažiem iemesliem, kāpēc. Varbūt jums varētu būt savas intereses, lai jūsu izstrādes un ražošanas būvniecības laiks tiktu ievērojami saīsināts.

Ir 2019. gads, mums vairs nav vajadzīgi lēni rīki

Lai arī Packem ir ātrāks par 4. tīmekļa paketi, tas ir vairāk nekā divas reizes ātrāks nekā Parcel (ar daudzkodolu kompilāciju) . Salīdzinošā testā mēs apvienojām Lodash v4.17.1 gan ar Packem, gan Parcel, un tas bija rezultāts:

Nekad neņemiet nevienu soliņu pēc nominālvērtības. Šeit varat to pārbaudīt pats.

Iemesls, kāpēc es neuztraucos salīdzināt paku ar webpack, bija tāpēc, ka 4. tīmekļa pakete ir dziļi ātrāka nekā paka. Es pierādīju šo faktu, izmantojot paša Šona T. Larkina soliņus, un pavedienu tam vietnē Twitter var atrast šeit.

Tāpēc, ka mēs varam. Ikviens var, vai ne?

Protams, visjūtīgākais būs tāpēc, ka mēs varam . Mums bija ideja par ātrāku saišu laiku ar Rusty saskarni vai nu ar FFI vai WASM (līdz tam vēl nebija pārliecināts). FFI bija saprātīgāks attiecībā uz ātrumu un DX, tāpēc mēs gājām ar to, ka Packem tika ieviests Rust FFI stiprinājumos.

Mums radās dažas ar pavedieniem saistītas problēmas, tāpēc daudz neizmantojām pieejamos resursus. Rezultātā mēs izmantojām vairākus mezglu pakārtotos procesus (ar mezglu-strādnieku-fermu ) to pašu paņēmienu, ko Parcel izmanto daudzkodolu kompilēšanai, bet lielākiem moduļu grafikiem, jo ​​tas pievieno ievērojamu startēšanas laiku virs mezgla darbspējas, ja to izmanto ar mazākiem moduļu grafikiem .

Konfigurācijas stils

Šī bija viltīga daļa. Bija daudz jautājumu, uz kuriem bija vajadzīga laba atbilde, lai izvēlētos pareizo konfigurācijas stilu. Statisks vai dinamisks? JSON / YAML / TOML? Mūsu izvēle pilnībā balstījās uz to, vai mums ir nepieciešams Packem, lai:

  1. Ir kārtīgāks konfigurācijas stils un
  2. Esiet agnostiķis attiecībā uz citām pielāgotajām lietotāju konfigurācijām, piemēram, .babelrc vai package.json .

Apakšējā līnija: mēs izmantojām statisku konfigurācijas stilu, jo mēs uzskatījām, ka tas ir tieši tas, kas mums nepieciešams. Kaut kas tāds, kas deklaratīvi varētu pateikt Packem, kā pārvaldīt saišu ciklu . Tika skaidri izteikti visi statiskās konfigurācijas ierobežojumi.

Vēl viens interesējošais aspekts bija faila tips, kas mums jāizmanto konfigurācijai. JSON, kas biežāk sastopams lielākajai daļai JavaScript izstrādātāju vai YAML / TOML / XML stila, kas ir retāk sastopami, bet kuriem ir savas priekšrocības. JSON atbalstam (# 5) joprojām tika izteikts ierosinājums.

JSON vienkārši neizgrieza visu nevajadzīgo virkņu pēdiņu, cirtaino un bloķējošo lencīšu dēļ, kas ir jēga, jo tas ir datu apmaiņas formāts . XML-ish pieeja nav pelnījusi cieņu attiecībā uz izmantošanu kā konfigurācijas formātu, jo tas padara lietas sliktākas nekā JSON, ciktāl tas attiecas uz nevajadzīgām rakstzīmēm. TOML ieviesa daudz jaunu līniju, un ligzdoto opciju atkļūdošana nešķita pievilcīga, jo mēs zinājām, ka Packem spraudņi var kļūt ļoti ligzdaini.

Galīgais uzvarētājs bija YAML! Tas spēja iziet cauri visiem aspektiem, lai tas būtu pareizs konfigurācijas formāts (vismaz Packem). Tas:

  1. Padara konfigurāciju nesāpīgu.
  2. Izmanto elegantu pieeju.
  3. Joprojām ir pazīstams JavaScript acīs
  4. Tika izstrādāts tieši šim lietošanas gadījumam (konfigurācijām) .

Šeit ir tipiskas Packem konfigurācijas piemērs ( packem.config.yml) . Pārbaudiet pats un padomājiet par tā paša satura rakstīšanu JSON / TOML / XML-ish stilā.

FYI, ir nepieciešamas tikai pirmās divas iespējas! ?

Pagarinot Packem

Šī funkcija vēl nav ieviesta.

Dažreiz mums var būt nepieciešams izmantot funkciju, kas vēl nepastāv , iespējams, ka tā nav ieviesta Packem vai ir ļoti specifiska mūsu projektam . Šajā gadījumā jums ir divi veidi, kā atrisināt savas vajadzības:

  1. Izveidojiet Packem spraudni savam lietojumam (kas ir ieteicamā opcija).
  2. Veidojiet pielāgotu RC virs Packem bināro failu.

Izmantojot Rust, mums ir iespēja pārveidot LC citos bināros formātos, piemēram, WebAssembly, kas ļaus Packem parādīt vairākus kompilēšanas mērķus:

  1. NAPI bāzes C / C ++ papildinājums ar platformai raksturīgiem bināriem, kas nepieciešami Packem noklusējuma RC.
  2. WebAssemble binārais binārs, kas ir starpplatforms un ievadīts RC.
  3. Packem noklusējuma savrupais, kas izmanto WebAssembly ar RC ar pārlūkprogrammu saderīgu ieviešanu.
Pēdējie divi vēl nav radarā, jo iekšējie pārstrādes darbi joprojām tiek sakārtoti.

Drīzumā ir paredzēts, ka uzlabotā rokasgrāmata parādīs, kā izveidot pielāgotu veidošanas rīku, izmantojot Packem bināros failus, lai tas atbilstu jūsu vajadzībām, ja jums Packem jālieto ārpus pārlūka un mezglu vides. Šīs binārās programmas pabeidz visu diagrammu ģenerēšanu un dublē filtrēšanu un citus ar diagrammām saistītus aspektus. Tas nozīmē, ka jūs varat izmantot savu pielāgoto serializatoru, failu vērotāju, spraudņu sistēmu utt. Tas ir līdzīgi tam, kā jūs varat izveidot savu pielāgoto renderētāju, izmantojot OpenGL.

  1. Jūs joprojām varat izmantot Packem spraudņu sistēmu, jo tas ļaus jums integrēt Packem spraudņu ekosistēmu ar jūsu pielāgoto paketi.
  2. Ja neesat pārliecināts, vai jums būs jāveido pielāgots saišķotājs, ziniet, ka tas jums ne vienmēr būs vajadzīgs. Lūdzu, vispirms mēģiniet iesniegt problēmu.
  3. Tas ir garantija, ka šie binārie faili paātrinās jūsu darbplūsmu atkarībā no konkrētā (-ajiem) lietošanas gadījuma (-iem).

Pašreizējais stāvoklis

  • ✂ Kodu sadalīšana izstrādes un ražošanas režīmiem.
  • ? Uzlabota CLI (`- verbose`), lai iegūtu labāku informāciju par komplektēšanas ciklu.
  • ? Moduļu saskarnes, kas ļauj viegli manipulēt ar moduļa diagrammu.
  • ✔ Pareiza prioritāte. Vietējās funkcionalitātes lieliski iederas LC. Tas nozīmē, ka pastāv lielākas iespējas ātri izveidot.
  • ? Eksportējiet N ativeUtils vietējo funkcionalitāšu ārējai lietošanai, ieskaitot g, enerateModuleGraph kas atkārtoti veic moduļa diagrammas ģenerēšanas procesu. Tas ir smags, taču joprojām ir noderīgs gadījumos, kad nepieciešams pašreizējā aktīvā moduļa diagrammas klons. Tā lietošana nozīmē uzbūvēšanas laika dubultošanu, tāpēc izmantojiet to uzmanīgi.

Ko tālāk?

Šīs ir iezīmes, kuras mēs ceram iegūt drīzumā gaidāmajos izlaidumos. Ar jūsu pūlēm mēs varētu paveikt komplektēšanu pareizi . Kad Packem ir 1.0 , mēs sagaidām, ka mēs pilnībā atbalstīsim visas tālāk uzskaitītās funkcijas un citas, kas minētas Packem ceļvedī.

  • Ar pārlūkprogrammu savietojams Packem atsevišķais elements ar WebAssembly LC, lai ciešāk integrētu pamata sistēmu. Aksels Raušmajers jau ir pieprasījis iespēju pieprasīt WASM ar Node saderīgu versiju. Lai reģistrētos, mēs drīz strādāsim pie abiem.
  • Treeshaking, bet progresējis. Nosauktu / nenosauktu importu atrisināšanai un mirušā koda noņemšanai vajadzētu būt vēsam. Tas nozīmē, ka jūs varat izmantot bibliotēkas, piemēram, lodash, nevis lodash-es , neuztraucoties, vai jūsu kods tiks izlaists vai nē.
  • Automātiskā konfigurēšana. Tāpat kā Zero Config, bet pēc noklusējuma orientēts uz papildu elastību.
  • Uzlabotas CLI iespējas, lai attīstīšana ar Packem kļūtu par otru dabu.
  • Labāka kļūdu ziņošana.
  • Vairāk vides mērķu. Sākotnēji Packem var kopēt tikai pārlūkprogrammu. Galu galā mēs ceram atbalstīt arī Node CJS un citus formātus.
  • Vairāk spraudņu. Mums vajag vairāk spraudņu! Lai ātrāk sāktu darbu, Packem ir kopīgs spraudņu komplekts. Bet, lai izaugtu kopiena, mums būs nepieciešama lieliska spraudņu ekosistēma. Pārbaudiet pieejamos parastos spraudņus vai vietnes spraudņu sadaļu, lai uzreiz sāktu izstrādāt spraudni.
  • Un daudz vairāk…

Resursi

  • Packem vietnē GitHub
  • Ceļveža un funkciju pieprasījumi
  • Packem oficiālā vietne
  • Spraudņu izveide ar Packem
  • Kodu sadalīšana ar Packem
  • Moduļu grafiks

Packem nav sasniegt 1,0 vēl . Ja esat atzinis, ka Packem jums vispār ir interesants, mēģiniet dot ieguldījumu pašā Packem, izveidojot spraudņus, atjauninot dokumentāciju, atbalstot mūs finansiāli, pārstāvot Packem konferencēs vai citos veidos. Mēs novērtējam jūsu centienus!

Priecīgu komplektēšanu! ???