Innhold
- 01. Skriv inn Node.js API
- 02. Si hei til npm 5
- 03. Oppdatert JavaScript-motor
- 04. Velkommen Async Hooks
- 05. Forbedret løftet støtte
- 06. Sikrere buffere
- 07. Endringer i feilsøking
- 08. Innføring av statiske feilkoder
Den siste store utgivelsen av Node.js gir mange viktige forbedringer i JavaScript-fellesskapet, inkludert en oppdatert JavaScript-motor, npm versjon 5, Googles V8, Node.js API, async_hooks, en WHATWG URL-parser, sikrere buffere og mer. Her oppdaterer vi deg om disse funksjonene og de andre viktigste aspektene av denne utgivelsen.
Node.js 8 er utgitt under kodenavnet Carbon, og er nå tilgjengelig fra Node.js-nettstedet. Det vil bli jobbet aktivt med i ytterligere 18 måneder (ingen nye funksjoner, bare feilrettinger, sikkerhetsforbedringer og npm-oppdateringer), før du går i vedlikeholdsmodus. Som med tidligere utgivelser, vil utgivelser under vedlikeholdsmodus bare motta kritiske sikkerhetsoppdateringer og feilrettinger.
- 20 JavaScript-verktøy for å blåse tankene dine
Det er trygt å si at siden Node.js har eksistert, er dette en av de største oppdateringene som kjøretiden noen gang har mottatt - det endrer hvordan innfødte tillegg er skrevet og gir også ytterligere sikkerhets- og ytelsesforbedringer.
RisingStack har hjulpet selskaper med å lykkes med Node.js i fire år med opplæring, rådgivning eller utvikling. En av de største kampene vi hadde var å legge til innfødte avhengigheter til prosjekter.
Før applikasjoner var avhengig av moduler med innfødt kode før Node.js 8, måtte du kompilere avhengighetene dine på nytt når store nye Node.js-versjoner kom. Hvis du var heldig, jobbet de først.
Denne prosessen ble gjort mulig med de enorme vedlikeholdene av arbeidsmodulene som ble lagt ned for å få modulene til å fungere på tvers av inkompatible Node.js-versjoner, for det meste ved hjelp av en modul kalt NAN (Node.js Native Abstractions).
Denne prosessen er langt fra ideell, siden mange selskaper ikke klarte å få oppdatert deres avhengighet hvis de ikke kunne kompileres, og det satte også en enorm ekstra arbeidsbelastning på modulvedlikeholdere. For å løse dette problemet ble Node.js API (eller N-API) introdusert.
01. Skriv inn Node.js API
Node.js API er en av de viktigste forbedringene av Node.js 8. Det bringer et veldefinert ABI (Application Binary Interface) til Node.js for å gjøre den virtuelle maskinen agnostisk. Dette betyr at native moduler ikke bare fungerer med forskjellige Node.js-versjoner ved hjelp av Googles V8 JavaScript-motor, men også med Microsofts Chakra.
Foreløpig er N-API i en eksperimentell tilstand, noe som betyr at betydelige endringer kan skje både med implementeringen og APIen. Med dette sagt, oppfordres innfødte modulvedlikeholdere til å prøve det nye grensesnittet og gi tilbakemelding.
Hvis du er modulholder, kan du frigjøre en N-API-versjon av modulen din parallelt med hovedmodulversjonen. For å gjøre dette er den offisielle anbefalingen å publisere en versjon av modulen din med n-api-koden til npm.
For å publisere en N-API-versjon, må du:
- Publiser den ikke-N-API-versjonen som vanlig.
- Publiser N-API-versjonen:
- Oppdater versjonen i package.json-filen ved å legge til en bindestrek og napi tag - så hvis du hadde 1.0.0 tidligere, blir den 1.0.0-napi
- Publiser til npm ved hjelp av npm publish --tag n-api
På denne måten sikrer du at N-API-versjonen ikke blir den siste utgivelsen, så hvis noen installerer modulen din, får de som standard ikke-N-API-versjonen.
Garn, pakkelederen opprettet av ingeniørene på Facebook, ble utgitt i oktober 2016. Den prøvde å løse noen mangler hos den offisielle npm-klienten, for det meste ved å bli mer performant og deterministisk. De fleste av disse innovasjonene er også omtalt i npm 5.
02. Si hei til npm 5
Akkurat som Garn introduserte npm 5 en låsefilmekanisme - hver gang du installerer en ny avhengighet av prosjektet ditt, vil det legges til automatisk ikke bare for å pakke.json, men en ny fil kalt package-lock.json også.
Du kan spørre hva forskjellen er mellom package-lock.json og npm-shrinkwrap.json, som npm-shrinkwrap har vært i npm siden for alltid? Lang historie kort, de er i det vesentlige de samme, men package-lock.json blir automatisk opprettet.
Hensikten er å beskrive nøyaktig hva avhengighetstreet npm må skape for pakken din. Hvis du har begge deler, npm-krympepapir vil ha forrang. Basert på anbefaling fra npm, bør du bruke npm-shrinkwrap.json hvis du vil publisere den, så bruker også modulforbrukerne den. På den annen side bør du bruke package-lock.json internt - til og med sjekket inn i repositories.
Men forbedringer av npm 5 har ikke stoppet med å legge til en låsefil - med den nye versjonen lagres også alle modulene du installerer, og de vil bli lagt til både i din pakke.json og package-lock.json fil.
Måten npm-skript fungerer på, har også endret seg litt. Først og fremst kjører nå forhåndsinstallerte skript før alt annet, slik at de kan endre katalogen node_modules før CLI faktisk leser den. I tillegg til dette er det lagt til to nye skript - prepack og postpack. De kjører begge på npm-pakke og npm-publisering også, men ikke på npm-installasjon.
I hjertet av Node.js er JavaScript-motoren som tolker JavaScript-koden din, oppretter bytekode fra den og lar applikasjonen kjøre. Med den nye Node.js 8-utgivelsen ble dette også oppdatert.
03. Oppdatert JavaScript-motor
Med den oppdaterte V8-motoren introduseres store ytelsesforbedringer - men enda viktigere, det er garantert å ha et fremoverkompatibelt binært grensesnitt. Dette betyr at Node.js vil kunne oppdatere V8-motoren uten en større Node.js-utgivelse.
Dette er avgjørende, ettersom de nyere versjonene av V8-motoren vil introdusere en ny kompilatorrørledning, som vil introdusere ytterligere ytelsesforbedringer til Node.js. Denne oppdateringen var så viktig at det var grunnen til at den opprinnelige utgivelsesdatoen for Node.js 8 ble utsatt.
Den nåværende rørledningen er altfor kompleks, og innføring av nye språkfunksjoner betyr vanligvis å berøre flere deler av rørledningen. Med den nye rørledningen blir det mye enklere.
Ignition, den nye tolk, og TurboFan, den nye optimaliserings-kompilatoren, har vært under utvikling i nesten tre og et halvt år. De er grunnlaget som nye språkfunksjoner skal bygges på. De inkluderer opplevelsen som V8-teamet på Google samlet fra måling av virkelige JavaScript-applikasjoner.
04. Velkommen Async Hooks
For å bedre forstå hva Async Hooks er, la oss ta et skritt tilbake og ta tak i videreføring-lokal lagring først. De fungerer som tråd-lokal lagring i gjenget programmering, men i Node.js bruker den tilbakeringinger for å overføre kontekst.
Tenk deg at du skriver et program som henter et produkt fra databasen, og senere vil du sende det ut i HTML-svaret:
const createNamespace = require ('continuation-local-storage'). createNamespace const session = createNamespace ('my-app-session') const db = require ('./ db.js') -funksjon onRequest (alternativer, neste) {db .fetchUserById (options.id, function (error, user) {if (error) {return next (error)} session.set ('user', user) next ()})
Senere, hvis du vil få tilgang til brukerobjektet, er alt du trenger å gjøre å hente det fra den lokale lagringsplassen:
const getNamespace = krever ('fortsettelse-lokal lagring'). getNamespace const session = getNamespace ('min økt') const render = krever ('./ render.js') funksjon avslutning (respons) {const user = session.get ('bruker') gjengi ({bruker: bruker}). rør (svar)}
Denne teknikken brukes mye av leverandører av applikasjonsytelsesovervåking, for eksempel Trace by RisingStack, for å holde kjøringskontekst og samle overvåkingsinformasjon fra produksjonssystemer.
Med Async Hooks blir en lignende funksjon flyttet til Node.js-kjernen - den hjelper med å spore asynkrone forespørsler og håndterere gjennom livssyklusen. De async_hooks modulen gir et API for å registrere tilbakeringinger som sporer levetiden til asynkrone ressurser opprettet i et Node.js-program.
05. Forbedret løftet støtte
Før Node.js 8, hvis du ønsket å bruke kjernemodulene i et program som bruker Promises, måtte du vikle kjernemodulene manuelt slik at de kunne brukes på samme måte. Det så ut slik:
const fs = krever ('fs') funksjon readFilePromise (... args) {return new Promise ((løse, avvis) => {fs.readFile (... args, (err, result) => {if (err ) {return løse (err)} løse (resultat)}}}} readFilePromise ('./pakke.json', 'utf-8'). så ((res) => console.log (res)) .fangst ((err) => console.log (err))
Med Node.js 8 blir en ny hjelpermetode lagt til i util-kjernemodulen, util.promisify. Det gjør at standard Node.js tilbakeringings-API-er kan pakkes inn i en funksjon som returnerer løfter.
Ved hjelp av denne funksjonen blir kodebiten ovenfor forenklet og blir denne:
const fs = krever ('fs') const promisify = krever ('util'). promisify readFilePromise = promisify (fs.readFile) readFilePromise ('./ package.json', 'utf-8') .then ((res) => console.log (res)) .catch ((err) => console.log (err))
06. Sikrere buffere
Før Node.js versjon 8 initialiserte ikke buffere som ble tildelt ved hjelp av den nye Buffer (Number) -konstruktøren minneområdet med nuller. Som et resultat kan nye bufferforekomster inneholde sensitiv informasjon, noe som kan føre til alvorlige sikkerhetsproblemer - selv populære moduler som Mongoose, ws eller forespørselsmodulen ble berørt.
Men hvordan kom vi dit? Da JavaScript ble flyttet fra nettleseren til serversiden, var det behov for rask og enkel databehandling - så bufferklassen ble lagt til. Buffer er et mutabelt utvalg av binære data. Når den brukes med konstruktøren som ber om størrelsen på den nye bufferen, reserverte den bare minneplassen, men ryddet den ikke.
Siden serveren din kan betjene flere brukere samtidig (i motsetning til nettleseren din), er det mulig at den nylig tildelte minneplassen inneholder sensitiv informasjon fra andre brukere (til og med passord!), Og potensielt kan bli utsatt for en angriper.
Selv om det var en bevisst beslutning om å øke ytelsen til den nye bufferopprettelsen, for de fleste av oss, var det ikke den tiltenkte bruken - selv om den var dokumentert. På grunn av dette, fra og med Node.js 8, vil buffere som er tildelt ved hjelp av ny buffer (nummer) eller buffer (nummer) automatisk fylles med nuller.
07. Endringer i feilsøking
Før Node.js 8, hvis du ønsket å feilsøke Node.js-applikasjonene dine, var en av de enkleste løsningene å starte den innebygde feilsøkingsprogrammet ved hjelp av nodfeilsøking index.js. Med Node.js 8 blir dette fjernet og erstattet av node-inspektør. Du kan fremdeles bruke CLI-feilsøkingsprogrammet, men det blir snart fjernet.
Fra nå av bør du bruke node --inspect index.js, eller node --inspect-brk index.js hvis du vil at feilsøkingsprogrammet skal sette et bruddpunkt på første linje i applikasjonen. Når du har kjørt den, vil du motta en WebSocket-lenke som Google Chrome kan bruke til å koble til feilsøkingsprogrammet.
Du bør gå over til chrome: // inspisere i Chrome-nettleseren din, og den vil automatisk gjenkjenne det kjørende Node.js-programmet, slik at du kan koble til. Etter at du har koblet deg til prosessen din, får du feilsøkingsprogrammet til Chrome til å inspisere ditt kjørende Node.js-program.
08. Innføring av statiske feilkoder
Tidligere, hvis du ønsket å sjekke en feil du mottok i løpetid og handle deretter, i de fleste tilfeller måtte du sjekke feilmeldingen. Dette var feil utsatt, ettersom feilmeldinger kan ha endret seg med nye Node.js-versjoner.
Med Node.js 8 er det tildelt statiske feilkoder til de fleste feilene - det er fortsatt et pågående arbeid, men når det er ferdig, vil disse feilkodene ikke endres, selv om meldingen i feilen gjør det .
For eksempel den nylig introduserte WHATWG URL API vil kaste en ERR_INVALID_URL feil i følgende kodebit, da parameteren ikke er en gyldig URL:
const URL = require (’url’). URL const myURL = new URL (’/ foo’)
Som du kan se, har utgivelsen av Node.js 8-oppdateringen gitt mange nye og spennende forbedringer i JavaScript-fellesskapet. For å begynne å eksperimentere med alle disse nye funksjonene selv, gå til nodejs.org, last ned Node.js 8 binær og begynn å spille med det nye verktøysettet!
Denne artikkelen dukket opprinnelig opp i nettmagasinet utgave 296. Kjøp den her.
