Software-update: Node.js 14.0.0

Node.js logo (75 pix) Node.js is open source en platformonafhankelijk, en is gericht op het ontwikkelen van server-sidewebapplicaties. Die applicaties worden geschreven in JavaScript en uitgevoerd binnen de Node.js runtime op de server. Het biedt een event-gedreven omgeving aan waarbij non-blocking i/o een belangrijk uitgangspunt is geweest. Voor meer informatie verwijzen we naar deze pagina. Het ontwikkelteam heeft versie 14.0 vrijgegeven en de belangrijkste verbeteringen die hierin zijn aangebracht zijn hieronder voor je op een rijtje gezet:

Deprecations
  • crypto: move pbkdf2 without digest to EOL #31166
  • fs: deprecate closing FileHandle on garbage collection #28396
  • http: move OutboundMessage.prototype.flush to EOL #31164
  • lib: move GLOBAL and root aliases to EOL #31167
  • os: move tmpDir() to EOL #31169
  • src: remove deprecated wasm type check #32116
  • stream: move _writableState.buffer to EOL #31165
  • doc: deprecate process.mainModule #32232
  • doc: deprecate process.umask() with no arguments #32499
ECMAScript Modules - Experimental Warning Removal
  • module: remove experimental modules warning #31974

In Node.js 13 we removed the need to include the --experimental-modules flag, but when running EcmaScript Modules in Node.js, this would still result in a warning ExperimentalWarning: The ESM module loader is experimental.

As of Node.js 14 there is no longer this warning when using ESM in Node.js. However, the ESM implementation in Node.js remains experimental. As per our stability index: “The feature is not subject to Semantic Versioning rules. Non-backward compatible changes or removal may occur in any future release.” Users should be cautious when using the feature in production environments.

Please keep in mind that the implementation of ESM in Node.js differs from the developer experience you might be familiar with. Most transpilation workflows support features such as optional file extensions or JSON modules that the Node.js ESM implementation does not support. It is highly likely that modules from transpiled environments will require a certain degree of refactoring to work in Node.js. It is worth mentioning that many of our design decisions were made with two primary goals. Spec compliance and Web Compatibility. It is our belief that the current implementation offers a future proof model to authoring ESM modules that paves the path to Universal JavaScript. Please read more in our documentation.

The ESM implementation in Node.js is still experimental but we do believe that we are getting very close to being able to call ESM in Node.js “stable”. Removing the warning is a huge step in that direction.

New V8 ArrayBuffer API
  • src: migrate to new V8 ArrayBuffer API #30782

Multiple ArrayBuffers pointing to the same base address are no longer allowed by V8. This may impact native addons.

Toolchain and Compiler Upgrades
  • build: update macos deployment target to 10.13 for 14.x #32454
  • doc: update cross compiler machine for Linux armv7 #32812
  • doc: update Centos/RHEL releases use devtoolset-8 #32812
  • doc: remove SmartOS from official binaries #32812
  • win: block running on EOL Windows versions #31954

It is expected that there will be an ABI mismatch on ARM between the Node.js binary and native addons. Native addons are only broken if they interact with std::shared_ptr. This is expected to be fixed in a later version of Node.js 14. - #30786

Update to V8 8.1
  • (SEMVER-MAJOR) deps: update V8 to 8.1.307.20 #32116
    • Enables Optional Chaining by default (MDN, v8.dev)
    • Enables Nullish Coalescing by default (MDN, v8.dev)
    • Enables Intl.DisplayNames by default (MDN, v8.dev)
    • Enables calendar and numberingSystem options for Intl.DateTimeFormat by default (MDN)
Other Notable Changes:
  • cli, report: move --report-on-fatalerror to stable #32496
  • deps: upgrade to libuv 1.37.0 #32866
  • fs: add fs/promises alias module #31553
Semver-Major Commits Semver-Minor Commits Semver-Patch Commits

Node.js

Versienummer 14.0.0
Releasestatus Final
Besturingssystemen Windows 7, Linux, BSD, macOS, Solaris, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website Node.js
Download https://nodejs.org/en/download/
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

23-04-2020 • 07:35

16

Submitter: cakemasher

Bron: Node.js

Reacties (16)

16
16
15
2
0
1
Wijzig sortering
Niet te snel upgraden met Node.js ben ik inmiddels achter. Libraries (via npm) e.d. lopen heel snel qua versies uit elkaar, in het gunstige geval krijg je allemaal warnings en werkt het nog, maar soms ook errors en werkt het niet meer.
Ik gebruik 'n' version management om dit soort dingen te voorkomen. Kun je makkelijk kiezen welke versie je wil gebruiken en ook net zo makkelijk weer terug gaan.
https://github.com/tj/n
Is hele goede tip, die gebruik ik inderdaad ook en dat is vaak wel een hele werkbare (tijdelijke) oplossing.
NVM wordt hiervoor ook veel gebruikt, onmisbaar vindt ik zelf als JavaScript developer, vooral als je zelf packages bouwt.
Op zich is dat best een goed devies. Daarbij wil ik toevoegen dat je met NVM (Node Version Manager) erg gemakkelijk kan schakelen tussen verschillende versies. Voor mij hielp NVM ook met een aantal issues die ik had rondom /usr/bin die de normale installer niet helemaal netjes deed.
Behalve als je zelf packages schrijft, ik heb gisteren diverse packages van mij getest met node 14, en bij mij werkten ze wel allemaal. (node 14 toegevoegd aan de bouw processen op travis en github)
Maar er zijn diverse grote oude logge packages met veel dependencies die vaker moeite hebben met upgraden.
In je project zelf kun je inderdaad beter nog een tijdje wachten.
Ja dat is dan ook de enige optie. Nou ja, ik heb wel goede ervaringen met het forken en aanpassen van bestaande modules inmiddels en ook voor modules waar verder al vier jaar niet naar gekeken is werkten pull-requests prima (de developers werden dan wel wakker gelukkig).

Alleen hele idee van packages is natuurlijk hergebruik, niet zelf het wiel opnieuw uitvinden, etc. Je leert er wel veel van daar om dingen van anderen te fixen e.d. maar het kost wel erg veel (kostbare) tijd.
Ik heb trouwens over eigen packages, 100% eigen code, niet over het forken van packages.

Bepaalde packages hebben vergelijkbare alternatieven, maar ik vindt het leuk om zelf te maken, en sluiten niet altijd aan bij mijn wensen. Het kost tijd, maar ik leer er ook van.

Het idee van packages is inderdaad hergebruik, daarom maak ik zelf ook packages, zodat ik in mijn applicaties steeds dat kan gebruiken.
JavaScript is niet echt mijn ding, leerzaam is het zeker, maar het leven is leren, vind het leuker om met hardware / cpp / python / Swift te werken, 't is omdat het moet m.b.t. JavaScript voor mij persoonlijk. Ben opgeleid vóór het web tijdperk en daarna meer de embedded kant opgegaan, je kunt je tijd helaas maar één keer uitgeven, heb met name veel hardware projecten lopen.

Verder ben ik het er enorm mee eens dat je er veel van leert. Hoewel ook jij ws. toch echt niet alles zelf zult schrijven (i2c / SPI libraries ik noem maar iets). Werkt overigens allemaal wel prima in JavaScript. Node.js is ook prettige 'uitvinding'.
Ik maak uiteraard ook gebruik van andere packages for mijn projecten.

Het was overigens ook niet mijn bedoeling om je te vragen om zelf packages te maken, en als JavaScript niet je ding is, en je focus ergens anders op ligt, zou ik ook geen packages zelf maken.
Het is een hel, maar met node kan je sowieso beter op de LTS blijven, dat raden ze zelf ook aan. Echter, gebeurd toch vaak dat project a een update doet waardoor de LTS niet meer voldoet, terwijl project b alleen werkt met LTS. Om droevig van te worden.
Het verwijderen van de ESM experimental flag is interesting. (ben een .io game aan het maken omtrent klimaatverandering omdat ik de gevolgen voor de komende 10000 jaar wil delen, advies blijf ver weg van de game industrie)

Onze node server side omgezet naar imports, incl de webpack configs.
  • 'Node(mon) server.js' draaien werkt
  • het builden via webpack helaas niet.
Waarschijnlijk doe ik iets fout, maar ik heb ook het idee dat bekende packages als 'html-webpack-plugin' en 'mongoose' nog niet klaar zijn hiervoor.

[Reactie gewijzigd door Harm_H op 22 juli 2024 21:48]

(ben een .io game aan het maken omtrent klimaatverandering omdat ik de gevolgen wil delen, advies blijf ver weg van de game industrie)
Toelichting? Bedoel je qua backend-kennis?
Dat de gameindustrie:
  • waarschijnlijk niets oplevert (net als muziek)
  • projecten inhoudelijk drie keer zo lang zijn
  • qua IT de meest veeleisende is van alle zakelijke sectoren
Ga maar na: een simpele zakelijke app maken is relatief simpel vergeleken met een complete interactieve game.

Elon Musk:
"I think many of the best software engineers in the world are at, or spent much of their career at, video game houses," Musk says, emphasizing how problem-solving in video games transfers over to problem-solving in software engineering. "If people had to try to create incredibly realistic graphics using very little computer power, it's a hard problem, so a lot of people had to write really tight code and come up with really clever ideas to do that."

[Reactie gewijzigd door Harm_H op 22 juli 2024 21:48]

Aan de andere kant denk ik dat een zakelijke omgeving heel andere eisen stelt en op die manier weer challenging is: zo zal disaster recovery belangrijk zijn in bepaalde sectoren (e.g. levensreddend) terwijl dit in de gameindustrie wat meer op de achtergrond zit. Beiden hebben dus volgens mij hun uitdagingen alleen op andere gebieden (bijv. 3D graphics vs. complexiteit van real-life processen).
Kan best zijn de de game-industrie moeilijk is om geld in te verdienen, maar veel lieden in dat wereld maakt dat ook niet zoveel uit. Dat is dan ook meteen een zelf versterkend effect, want hoe kan je bijvoorbeeld een dik salaris vragen als er talloze anderen hetzelfde voor minder doen.
Je had dit ook een tijd in de architecten wereld. Daar werd vaak niet eens een minimum salaris betaald aan (startende) architecten omdat er zoveel waren die het ook voor weinig / niets deden.

Op dit item kan niet meer gereageerd worden.