GitHub neemt JavaScript-ontwikkelaarsplatform npm over

GitHub, het in 2018 door Microsoft overgenomen ontwikkelaarsplatform, koopt npm Inc. Dit is het bedrijf achter Node package manager, een JavaScript-ontwikkelaarsplatform. Het idee is dat GitHub en npm op de langere termijn worden samengevoegd.

GitHub-ceo Nat Friedman zegt dat npm altijd beschikbaar zal blijven en altijd gratis zal zijn. Nadat de overeenkomst definitief is, zal GitHub zich volgens Friedman onder meer richten op het investeren in de registry-infrastructuur, omdat het JavaScript-ecosysteem snel groeit. Deze investeringen moeten ervoor zorgen dat npm 'snel, betrouwbaar en schaalbaar' is. Daarnaast wil GitHub het werk ondersteunen dat al is begonnen voor npm v7 CLI; dit blijft open source.

Laurie Voss, medeoprichter van npm, zegt dat het voor altijd laten draaien van de registry in de afgelopen vijf jaar zijn voornaamste drijfveer was bij npm, en dat dat nu verzekerd is door de overname. Volgens Voss is GitHub het meest logische bedrijf om met npm samen te gaan; hij zegt blij te zijn dat dit mogelijk is geworden.

Op een npm-blog zegt de oprichter, Isaac Z. Schlueter, dat het beperken van de frictie in de ontwikkeling van JavaScript-software altijd de voornaamste missie van het bedrijf is geweest. Hij omschrijft dat het laten draaien van een bedrijf moeilijk was en dat deze overname als een overwinning gezien moet worden, zowel voor de medewerkers van npm Inc. als voor de JavaScript-gemeenschap.

Volgens Microsoft ondersteunt npm inmiddels meer dan 1,3 miljoen packages voor ongeveer twaalf miljoen ontwikkelaars, die deze zaken maandelijks zo'n 75 miljard keer downloaden. Hoeveel geld Microsoft voor de overname neerlegt, is niet bekendgemaakt.

Reacties (72)

Microsoft's strategie is om developers op hun cloud te krijgen. Straks hebben ze je editor (visual studio code), je source control (github) én package manager in handen. Zal me niet verbazen als ze het commanda 'npm azure-run' o.i.d. gaan toevoegen aan de standaard npm versie. Dagelijks honderdduizenden (trial) gebruikers van je cloud platform erbij. Onder het mom: 'mijn code draait al op azure, moeten we het nu nog gaan migreren naar iets anders?'

Je zou wel eens gelijk kunnen hebben.
Wel een beetje off topic, maar ben ik de enige die mij verbaast over de enorme hoeveelheid overhead en ondoorzichtige dependencies in de packages? Dat moet toch slimmer kunnen?

Die overhead valt (in JS-land) behoorlijk mee, mits je enkel "single-responsibility" dependencies gebruikt, oftewel dependencies die precies één duidelijk-gedefinieerd doel hebben. Dan haal je qua dependencies alleen maar de complexiteit binnen die je applicatie ook daadwerkelijk nodig heeft om zijn werk te doen.

Dat is anders wanneer je "kitchensink"-dependencies gebruikt die van alles en nog wat proberen te implementeren, en die vaak dan weer op andere kitchensink-dependencies bouwen, enzovoorts... dan is het gros van de complexiteit in je applicatie volledig overbodig, en zit het er alleen maar in omdat het toevallig samen verpakt was met dat ene ding dat je wél nodig had. Een bekend voorbeeld hiervan is Underscore/Lodash.

Het aantal dependencies zelf lijkt al snel hoog, maar zegt eigenlijk niets. Als je 1 monolithische probeert-alles-te-doen dependency hebt, dan heb je al snel veel meer complexiteit in je applicatie zitten dan wanneer je 1000 single-responsibility dependencies gebruikt, puur omdat er zoveel onnodige meuk meeverpakt wordt.

Eigenlijk is een hoog aantal dependencies dus vaak een indicator dat er juist weinig complexiteit in een codebase zit, want zo'n hoog aantal krijg je normaliter alleen maar als je single-responsibility dependencies gebruikt. Een 'dependency' is uiteindelijk puur een verpakkingsunit en brengt an sich geen kosten met zich mee, en die wil je dus liefst zo granulair mogelijk hebben.

Edit: Die laatste opmerking geldt dus specifiek voor JS. In veel andere talen brengen dependencies wél inherente kosten met zich mee, omdat ze een ander dependency-model hanteren.

[Reactie gewijzigd door svenslootweg op 16 maart 2020 22:46]

Niet helemaal hetzelfde misschien, maar hoe zou jij dit oplossen voor JQuery en JQueryUI?
Zo had ik eens JQuery UI helemaal moeten includen om enkel de functionaliteit 'scroll to anchor-id on button click' te implementeren. Wat dus resulteerde in een grote overhead.

Als ik dan via een test-tool kijk welke Javascript code mijn website gebruikt in de gewone JQuery library is dit ook maar 30%. Dus 70% overhead.

Een tool die enkel de gebruikte Javascript uit libraries zou kunnen scrapen zou ideaal zijn, maar bestaat niet...

Niet helemaal hetzelfde misschien, maar hoe zou jij dit oplossen voor JQuery en JQueryUI?

Heel bot gezegd: geen jQuery en jQueryUI gebruiken. Of iets monolithisch of modulair / single-responsibility is, is een eigenschap van de library zelf en hoe deze ontworpen is. Dat kun je niet achteraf als gebruiker beinvloeden.

Wil je van de overhead van jQuery af, dan is het dus zaak om een alternatief te vinden. In veel gevallen betekent dat een andere library zoeken die alleen hetgeen doet dat je voor je applicatie nodig hebt - in heel veel gevallen kun je een dergelijke library dus gewoon op npm vinden. In sommige gevallen is er eigenlijk geen meerwaarde in een library, omdat de exacte functionaliteit die je zoekt al native ondersteund wordt.

Dat is ook het geval voor jouw usecase; naar een bepaald punt op de pagina scrollen is iets dat een browser zelf ook prima kan. Dan moet je er wel een hyperlink van maken i.p.v. een button (en desnoods via CSS de stijl aanpassen), maar voor een ding met navigatie-actie is dat sowieso een goed idee, semantisch gezien. Je wijst je hyperlink naar #jouw-anchor-id-hier en klaar is kees, niet eens JS voor nodig.

Een tool die enkel de gebruikte Javascript uit libraries zou kunnen scrapen zou ideaal zijn, maar bestaat niet...

Dat bestaat wel: dit heet "dead code elimination", en de specifieke implementatie die veel in JS gebruikt wordt heet "tree shaking". Echter is het niet bijster nuttig; het ontwerp van JS als taal maakt het moeilijk om betrouwbaar te bepalen welke code wel of niet in gebruik is, waardoor een dergelijke tree shaker niet alle ongebruikte code zal kunnen verwijderen.

Bovendien heb je het probleem van een monolithisch ontwerp; niet alleen betekent dat dat er veel (onnodige) gedeelde code gaat zijn omdat de hele library om een heel eigen ontwerpmodel heen gebouwd zal zijn (waardoor je dus alsnog veel rommel overhoudt die "gebruikt" wordt maar eigenlijk niet nodig is), er zijn ook nog andere kosten van het gebruik van monolithische libraries waar een treeshaker niets aan kunt doen.

Denk hierbij bijvoorbeeld aan de hoeveelheid complexe code die je moet lezen als je je dependencies wilt auditen, of de extra code die je nodig hebt om een monolithische library (die alleen ontworpen is om met z'n eigen functies te werken) samen te laten werken met een andere library. Je zult er altijd meer werk aan overhouden.

De enige oplossing hier is om simpelweg monolithische libraries helemaal te vermijden, en alleen modulaire dingen te gebruiken. Die zijn specifiek ontworpen om zonder gedoe met alle andere denkbare dingen geintegreerd te kunnen worden (ze maken weinig aannames over wat je applicatie precies doet of hoe), en omdat de individuele packages klein zijn is er weinig ruimte voor libraries om complexiteit te ontwikkelen die het auditen of fixen van de code moeilijk maakt.

Dat je daardoor ook kleinere JS bundles naar de browser kunt sturen, omdat de complexiteit er uberhaupt niet is en dus ook niet verwijderd hoeft te worden, is dan een mooie bonus.

[Reactie gewijzigd door svenslootweg op 17 maart 2020 01:03]

Zou je niet je code (inclusief dependencies) kunnen draaien in een debugger, en automatisch noteren welke regels code er allemaal uitgevoerd worden tijdens het draaien? Dan zou je al die regels kunnen laten markeren in je code editor; je ziet dan makkelijk welke stukken je zó kunt schrappen.

Is voor een dynamische taal zoals javascript niet echt mogelijk. Daarnaast gaat dit dezastreus zijn.

Voorbeeld: regel code die triggert op schrikkeldagen. Stom voorbeeld, maar markeren welke code in het wild gebruikt gaat worden is een nontriviaal probleem.

Hoe bedoel je, niet echt mogelijk?

Het zal inderdaad nooit volledig automatisch mogelijk zijn. Maar zoiets als ik beschreef kan het wel heel veel makkelijker maken om de code door te spitten.

Hartelijk bedankt voor je antwoord!

Dank je wel voor de huidige uitleg. Als Python developer weet ik maar al te goed wat grote dependencies doen.

Een tool die enkel de gebruikte Javascript uit libraries zou kunnen scrapen zou ideaal zijn, maar bestaat niet...

Zoek eens op wat tree-shaking is.

Het web kent enorm veel edge-cases. In principe zou je als je goede testing heb alle ongebruikte code weg kunnen compileren maar dat is heel moeilijk in de praktijk.

Wel een beetje off topic, maar ben ik de enige die mij verbaast over de enorme hoeveelheid overhead en ondoorzichtige dependencies in de packages? Dat moet toch slimmer kunnen?

Je bent niet de enige en ikzelf liep in het begin dan ook met een grote boog om npm heen. "Want je hebt het src-attribuut van de script-tag toch al?" Inmiddels zie ik het praktisch nut er wel van in.

Maar, je moet kritisch blijven op de gezondheid van de dependencies die je gebruikt.

Maar, je moet kritisch blijven op de gezondheid van de dependencies die je gebruikt.

En dit is iets wat eigenlijk niet gebeurd. Als ik een package toevoeg kijk ik naar de leeftijd van het project, laatste commits en hoe er met issues en Pull Requests wordt omgegaan. Helaas zie ik regelmatig dat mensen het eerste pakken wat ze vinden ondanks dat het al 4 jaar niet meer geupdate is en twee weken later afvragen waarom het niet op de nieuwste browsers werkt.

Microsoft's strategie is om developers op hun cloud te krijgen. Straks hebben ze je editor (visual studio code), je source control (github) én package manager in handen. Zal me niet verbazen als ze het commanda 'npm azure-run' o.i.d. gaan toevoegen aan de standaard npm versie.

Hebben ze dat ook met NuGet gedaan dan?

In zekere zin wel. Voer maar eens [mono] dotnet add package <PACKAGE_NAME> [/] uit zoals beschreven op https://docs.microsoft.co...l-use-packages-dotnet-cli

[Reactie gewijzigd door Stoelpoot op 18 maart 2020 09:38]

Gelukkig zijn er voor zowel VSCode als voor github goede alternatieven. Node/NPM trouwens ook, al dan niet specifiek JS

Er zijn alternatieven, maar de truc is dat mensen niet graag switchen. Als jebijvoorbeeld alle shortcuts en extensies van VSCode gewend bent en alles hebt geconfigureerd voor jouw workflow en jouw projecten, dan is het niet aantrekkelijk vim te leren én te configureren.

Klopt. Ik merk dat bij mezelf, ik ben vim gewend en ben pas 2 jaar met Atom bezig. Hoe vaak ik nog :wq intik per ongeluk....

Waarom niet gewoon vim keybindings/emulation mode (de ene editor plugin is al wat meer echt vim dan de andere) gebruiken in atom? Dat doe ik in al mijn editors, dat werkt veel vlotter en dan werkt :wq ook gewoon.

[Reactie gewijzigd door mdgf op 17 maart 2020 11:18]

Ja, dat kan. Echter wil ik Atom gebruiken zoals de auteurs het bedoeld hebben. Dus is het mezelf aanpassen.

Kun je de key binding dan niet gewoon aanpassen? Of Autohotkey gebruiken om het automatisch te fiksen?

Nee, gezien Atom en vim compleet anders werken. Zover ik weet werkt Autohotkey alleen in Windows

Dan toch maar eens VS Code proberen, die ondersteund via een extensie de vim manier van werken

Atom ook ;-)
Ik vind VSCode helemaal niks, teveel popups/banners dat "feature X of Y pas werkt na installatie van pakket Z of A"

Het alternatief is dat npm gewoon offline gaat, want het bedrijf erachter zat in de problemen. Er zijn voor alle bovengenoemde opties voldoende alternatieven. GitLab of self-hosted GitLab, BitBucket, etc. Voor VS Code (is open source, dus geen idee waarom je daar af zou willen) heb je bvb. IntelliJ, Atom, Sublime, etc. of Notepad/Notes in any OS als je echt omhoog zit.

Moet eerlijk zeggen dat ik als developer mijn eigen GitLab server draai, een combinatie van Sublime Text en IntelliJ IDEA gebruik en NPM eigenlijk alleen maar nodig heb voor niet-development doeleinden. Microsoft heeft misschien mijn OS, maar dat is dan ook het enige.

Dat is allemaal mooi. Maar deze baart me zorgen:
....voor npm v7 CLI ; dit blijft opensource.

Dus ik lees, niet allles, er gaan dingen veranderen.

Waar haal je dat uit? De CLI is open source, GitHub heeft gezegd dat dat zo blijft en jou conclusie is: "dus het blijft niet zo"?

Hij maakt zich zorgen omdat wellicht alleen v7 CLI (wat dat ook betekent) open source blijft.

Niet vergeten dat je naar je code ssh't en remote edit.

Ik heb geen idee hoeveel software er geschreven wordt in Javascript/node, maar de software development wereld bestaat uit meer dan dat.

Poeh, dit zet me wel aan het denken. npm is best wel een belangrijk deel van de javascript infrastructuur waar Github/Microsoft nu controle over krijgt. Ik heb me eerlijk gezegd nooit gerealiseerd dat er überhaupt een bedrijf achter npm zat.
Het gaat dus over van het ene bedrijf naar het andere bedrijf, dus wat dat betreft veranderd er eigenlijk niks, maar het wordt nu wel eigendom van een van de grote internetreuzen die langzaam de hele IT wereld opslokken.

Het verbaasd mij wel dat dit zo'n grote deel heeft veroverd, terwijl het niet goed in elkaar zit.

• Je download 100-en MB's om maar met een paar MB een applicatie te maken.
• De repo bestaat uit losse bestanden. Niet eens een zip. Downloaden of kopiëren duurt daardoor ook lang.
• De repo is per project.
• Veel kleine projecten.

Het kan echt vele malen beter en sneller.

De manier waarop de npm package manager werkt is in bepaalde opzichten niet optimaal, vooral m.b.t. file management. Daar wordt o.a. met Yarn Plug’n’Play hard aan gewerkt.

npm is zo succesvol omdat het een probleem oplost voor veel ontwikkelaars, namelijk het gemakkelijk delen en gebruiken van JavaScript packages. Bovendien liftte het mee op het succes van JavaScript zelf. Hoe het zich manifesteert op je harddisk is van ondergeschikt belang. 100MB aan files is niet echt een groot probleem voor de machines waar ontwikkelaars meestal mee werken. En hoeveel van dat soort grote projecten werk je nou daadwerkelijk tegelijkertijd aan? Het mooie van node_modules is dat je hem volledig kan trashen en op elk moment opnieuw kunt opbouwen.

Het hele npm ecosysteem werkt volgens de unix filosofie waarbij software modulair wordt opgebouwd uit minimalistische packages. Dat heeft veel voordelen (o.a. herbruikbaarheid, onderhoudbaarheid), en ook wat nadelen (o.a. overzichtelijkheid, beheersbaarheid). En soms gaat het mis, zoals met left-pad. De heersende gedachte is dat de problemen wel zijn op te lossen met tooling (o.a. Yarn PnP) en regels (unpublishen niet mogelijk na 72 uur). Ik ben ervan overtuigd dat de problemen die je noemt over 2 jaar niet meer van toepassing zijn omdat de tooling nog steeds grote sprongen maakt. Met Microsoft er achter zal dat alleen nog maar meer het geval zijn.

Het verhaal van left-pad beschrijft wel een probleem wat hier nog groter word:

This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because, Power To The People.

Summary; NPM is no longer a place that I’ll share my open source work at, so, I’ve just unpublished all my modules.

Dat is wel interessant, want stel dat er een kleine exodus is, waarbij sommige ontwikkelaars hun modules 'depubliceren'.

Wat is dan de licentie van die modules; wie is eigenaar van de code, mag Microsoft ze nog terugzetten?

Alles wat MIT is of GPL, en waar Microsoft een back-up van heeft, kunnen ze mijns inziens terugzetten. En als de ontwikkeling van die pakketjes ergens anders verdergaat onder die licentie, kan MSFT ze kopiëren naar hun NPM.

En hoeveel procent van de modules kan verdwijnen voordat npm onbruikbaar wordt?

En hoeveel procent van de modules kan verdwijnen voordat npm onbruikbaar wordt?

Bijzonder weinig: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

[Reactie gewijzigd door Robtimus op 17 maart 2020 10:49]

De restore tijden zijn idd extreem traag met npm. Haalt ook niet echt uit wat voor package manager je gebruikt. Het is gewoon van de zotte dat het minuten duurt op een modern systeem met snel internet.

Het heeft ook te maken met de gigantische hoeveelheid packages die je moet downloaden omdat een package vaak maar enkele functies (soms letterlijk maar 1...) bevat. Ik denk dat men een beetje is doorgeslagen in het uitsplitsen van de code in aparte packages. Leuk architectureel gezien maar er zit natuurlijk een overhead aan elke package.

De restore tijden zijn idd extreem traag met npm. Haalt ook niet echt uit wat voor package manager je gebruikt. Het is gewoon van de zotte dat het minuten duurt op een modern systeem met snel internet.

Restore je middels npm ci of middels npm install?

De tweede kijkt naar transitieve dependencies; beschikbaar en compatible versie-bereik; doet de-duplication en structuurwijzigingen aan de package-graph; etc.
Maar de eerste neemt linea recta exact de package-structuur, versies en download URLs uit het package-lock.json file en doet verder niet veel anders als tgz files downloaden en uitpakken in een voorafvastgelde directory structuur.

De tweede is wat je zou moeten gebruiken om te restoren.
De eerste is wat je ... eigenlijk nooit zou moeten gebruiken. npm install zonder een package argument is eigenlijk gewoon legacy bagage.

Jammer genoeg is er nog veel tooling, zelfs koplopers als Visual Studio 2017/2019, die niet npm ci maar npm install gebruikt als restore commando.


[EDIT]
Internet-snelheid heeft trouwens op secundaire restores weinig invloed; NPM hanteert een lokale cache.

[Reactie gewijzigd door R4gnax op 16 maart 2020 22:39]

Npm ci moet je alleen op je build server gebruiken. Vandaar dat de naam ook ci is (continuous integration). Een aantal zaken worden overgeslagen zoals jij al aangaf, ook de cache valt hieronder. Daarnaast delete deze de node modules folder mocht deze bestaan.

Voor lokale development zit je dus nog wel vast aan npm install.

Npm ci moet je alleen op je build server gebruiken. Vandaar dat de naam ook ci is (continuous integration). Een aantal zaken worden overgeslagen zoals jij al aangaf, ook de cache valt hieronder. Daarnaast delete deze de node modules folder mocht deze bestaan.

Voor lokale development zit je dus nog wel vast aan npm install.

Cache valt daar niet onder. De officiële handleiding voor het commando geeft zelf een Travis CI configuratie die expliciet ingericht wordt om de lokale cache te behouden en te kunnen hergebruiken in volgende CI builds. Er is daarnaast ook nog een expliciete --prefer-offline flag die de cache minimum time negeert en direct de packages uit de lokale cache pakt zonder dat er gedwongen opnieuw geverifieerd moet worden met een online registry.

En uiteraard gooit het ci commando de hele node_modules folder weg. Het hele idee is dat je middels het lock file een compleet 100% gegarandeert identieke tree kunt repliceren. Dit in tegenstelling tot situaties waar meerdere developers door het gebruiken van incrementele install commando's andere trees met andere versies voor transitieve dependencies kunnen krijgen. Oftewel; als je met meer dan 1 developer in een team werkt, werk je altijd met het ci commando en niet met het install commando.

[Reactie gewijzigd door R4gnax op 17 maart 2020 01:06]

Volgens mij staat ci in deze voor clean install zie ook de officiële documentatie.

This command is similar to npm-install, except it’s meant to be used in automated environments such as test platforms, continuous integration, and deployment – or any situation where you want to make sure you’re doing a clean install of your dependencies. It can be significantly faster than a regular npm install by skipping certain user-oriented features. It is also more strict than a regular install, which can help catch errors or inconsistencies caused by the incrementally-installed local environments of most npm users.

Bron: https://docs.npmjs.com/cli/ci.html

Je download 100-en MB's om maar met een paar MB een applicatie te maken.

Dat probleem krijg je voornamelijk als mensen hun packages niet juist inrichten en bijv. de volledige unit test infrastructuur er in rammen, en ook niet de moeite hebben genomen om (public) dependencies netjes van dev(eloper) dependencies te scheiden.

De repo bestaat uit losse bestanden. Niet eens een zip. Downloaden of kopiëren duurt daardoor ook lang.

Wat je downloadt is toch echt een tgz archive. Hetzelfde soort als wat je met een npm pack commando maakt en wat npm publish ook daadwerkelijk zou uploaden naar een registry.

[Reactie gewijzigd door R4gnax op 16 maart 2020 22:37]

Dit gaat vooral om de ontwikkeling, dan wil je gewoon alle bestanden hebben en alles kunnen debuggen. Een gecompileerde versie kun je altijd maken met elk framework en library. En dat is ook wat de meesten consumeren, maar door alle sources te hebben, kun je dus verder gaan. NPM is om projecten te bouwen, niet om ze te runnen.

Ik zie NPM als Lego.
Met een los Lego blokje heb je nog niet veel, je hebt veel blokjes nodig voor en volledig iets.

Bij het openen vindt je soms honderden bouwblokken, soms vage, elk heeft vaak een kleine scope.

Bij NPM zijn alle blokje los verpakt met een eigen instructie.
Je hebt dus veel afval, wat je niet in het bouwwerk terug zal zien, alleen waar je het bouwt.

Vele anderen (composer bijvoorbeeld) zijn meer als Playmobil, bij het openen vindt je vaak grotere onderdelen, elk onderdeel heeft een grote scope, een duidelijker doel.
Hierdoor is de berg met overhead kleiner.

Beide hebben voorbeelden.
De ene vindt het ook leuker om met Lego te spelen, de andere liever met Playmobil.

NPM was al groot (1,231,869 pakketten volgens hun live teller), daar moet dus wel een bedrijf achter zitten wil je de boel draaiend kunnen houden. Wel zijn het uiteindelijk allemaal startups, die veelal met durfkapitaal groot worden en (mogelijk) daarbij verliest draaien. Of dat voor NPM was/is, weet ik niet, maar de meeste grote namen in deze business zijn over het algemeen nog altijd niet winstgevend of worden vervolgens weer verkocht.

npm, Inc. is in het verleden in het nieuws geweest omdat het mensen de laan uit moest sturen vanwege geldgebrek. Vorig jaar was het bedrijf nog bijna kopje onder gegaan, ze hadden nog geld om de servers ongeveer een maand in de lucht te houden. Daar is toen net op tijd een geldschieter voor gevonden.

[Reactie gewijzigd door GHengeveld op 16 maart 2020 21:30]

Zal tot die tijd wel een kleine exodus naar yarn plaatsvinden, gelijk aan toen projecten van Github naar Gitlab overstapten na de overname door Microsoft.

Yarn is van Facebook toch? Niet echt een betere kandidaat als je het mij vraagt...

Ik heb 100000 keer liever dat het Microsoft het bedrijf achter de registry of tooling is dan Facebook! Zonder enige vorm van twijfel.

De stappen die Microsoft de laatste jaren gezet heeft richting de open source community is op zijn minst bewonderenswaardig!

Github is er wel op vooruit gegaan sinds de overname door Microsoft. Nieuwe features en ook onderdelen die juist gratis zijn geworden die eerst betaald waren.

Klopt wel. Het is ook meer een hypothese dan een advies.
Hoewel veel features zijn overgenomen van Gitlab. Die project boards werken erg fijn. Je hebt geen Trello meer nodig.

GitLab heeft anders ook e.e.a. van GitHub overgenomen.

Yarn is slechts een alternatieve CLI voor dezelfde registry, die van npm. Er is wel een registry.yarnpkg.com maar die forward alles naar registry.npmjs.org. Een exodus naar Yarn schiet je dus niks mee op. Zou natuurlijk wel kunnen dat de ontwikkelaars van Yarn een echte eigen registry beginnen, maar die kans lijkt me zeer klein. GitLab support overigens wel een eigen npm registry maar die is alleen voor je eigen packages.

Dat is wel erg naïef , wie moet die infra structuur betalen?

Waarschijnlijk zal het op dezelfde infrastructuur gaan draaien als nuget. De afgelopen jaren is er een verschuiving ontstaan rendering steeds minder vaak op de server plaats vinden. SPA frameworks zoals Angular, Vue, Kendo, ExtJs, etc worden steeds populairder..

Voor Microsoft is een goede development ervaring belangrijk. Package management maken development eenvoudiger. De overname van NPM zorgt ervoor dat Visual Studio en VSCode ontwikkelaars gebruik kunnen blijven maken van deze tooling..

Ik vind het een goede stap. Inmiddels heeft Microsoft Github ook gratis gemaakt voor private repositories waarbij het dat al veel eerder had gedaan voor hun Azure DevOps omgeving..

TypeScript is ook van Microsoft, dus ze zitten al behoorlijk in dat eco-systeem. Maar als ik eerlijk ben doet Microsoft het uitstekend en is Github er alleen maar beter van geworden.

/offtopic: developer developers developers

/ontopic:
Tja, voor een private equity funded bedrijf zijn er maar een paar exit manieren. Dit is wel de beste oplossing die mogelijk was.

npm runnen op centrale servers is heel dure grap daar moet je wel kapitaal krachtige partij achter zetten. Na aanvankelijke scepsis zijn meeste mensen heel tevreden hoe Microsoft Github managed en ontwikkeld. NPM moet veel decentraler gaan worden.

Mooie aankondiging. Het meeste liep al via github, dus dit is niet onverwacht. Ik ben wel benieuwd of Microsoft nu ook nog op NodeJS aast. Want die stap is nu makkelijk gezegd natuurlijk.

En het is lastig om te oordelen hoe het gaat ontwikkelen. Alles op 1 bedrijf zetten is ook niet handig, maar een project als dit kost veel geld met een grote infrastructuur. Ik denk dat NPM ook niet lang zelfstandig had kunnen blijven in huidige vorm.

En voor Microsoft is het duidelijk dat ze bij de webtechnieken liever een open systeem hanteren omdat dan het aandeel vanuit de community vele malen groter is. Ze hebben ondertussen aardig wat webdiensten lopen en dan is het dus handig als er nog veel ogen naar je projecten blijven kijken. Het is niet alsof ze nu kunnen zeggen "JavaScript is van ons". Alles wat ze achter gesloten deuren willen zetten, schieten ze zichzelf alleen maar mee in de voet.

Edit: het betreft hier een mail van npm idd. Was ff mobiel dus wat kort door de bocht.

We are excited to share the news that npm will be joining GitHub!

This is great news for all npm users: Our commitment to keeping the npm Registry free for open source development will continue with no change. We are looking forward to being part of GitHub,
a company as committed to open source and the long-term success of the JavaScript community as we are.

Whether you use the Registry for free, or with one of our premium products, today's announcement does not change anything in your day-to-day work.

For more details on the next chapter for npm, check out Isaac’s blog post. And if you have immediate questions, please reach out.

-The npm Team

[Reactie gewijzigd door Ed Vertijsment op 16 maart 2020 22:00]

Misschien handig als je er een bron bij zet. Nu lijkt het alsof je zelf van het NPM-team bent (of gewoon een copy paste hebt gedaan). Als je dat bent, zou je dat wat duidelijker neer kunnen zetten.

[Reactie gewijzigd door AnonymousWP op 16 maart 2020 20:35]

Dit staat in de email die je ontvangt als je zelf een package maintainer bent.

Dan kan hij dat toch gewoon neerzetten? Kost 10 seconden meer werk om "heb ook een e-mail ontvangen van NPM-team:" of "ik ben een package maintainer en bla bla".

[Reactie gewijzigd door AnonymousWP op 16 maart 2020 20:45]

Dat klopt. Ik zeg het even om tot die tijd de verwarring weg te nemen.

Misschien handig als je er een bron bij zet. Nu lijkt het alsof je zelf van het NPM-team bent (of gewoon een copy paste hebt gedaan). Als je dat bent, zou je dat wat duidelijker neer kunnen zetten.

Het staat er toch ook boven wat het is? Het is een EdVertijsment .

Verschillende developers die ik op Twitter volg zijn blij met het nieuws. Ik wacht het nog even af.

Ik werk zelf dagelijks met npm (beheer diverse packages) en ben zeer te spreken over deze stap. npm, Inc. heeft in het verleden diverse foute stappen gezet waar de hele community niet over te spreken was. Aangezien de financiele situatie van het bedrijf was zorgwekkend, terwijl de npm registry cruciale infrastructuur is voor een groot deel van alle software ontwikkeling die wereldwijd gedaan wordt.

Met GitHub / Microsoft er achter kunnen we eindelijk met een gerust hart ons werk doen (Corona buiten beschouwing gelaten), en gaan we hopelijk weer wat innovatie / verbeteringen zien. Tot nu toe was het alleen Yarn wat met betere tooling kwam, maar zonder invloed op de registry zelf ben je beperkt in wat er mogelijk is. Je kunt sceptisch zijn over de beweegredenen van Microsoft (simpel: iedereen op Azure, dat is waar het geld verdient wordt), maar van diverse insiders hoor ik alleen maar hoopgevende signalen, en de laatste jaren hebben ze zich echt van hun beste kant laten zien.

Vind het ook wel een goede actie. Github had al een 'used-by' counter voor package repositories en de meeste code staat toch al op Github én NPM.

Trouwens, ik zou NPM niet een ontwikkelaarsplatform noemen maar een Javascript package manager (Javascript code pakket beheersysteem als het Nederlands moet). De enige reden dat iedereen het gebruikt, is omdat alle (99%) tooling omtrent Javascript development ermee om kan gaan. Het was bedoeld voor Node.js (gebaseerd op de Javascript V8 engine van Google Chrome maar dan voor de desktop), maar bevatte al snel ook browser-only packages.

De overname past heel mooie bij de huidige manier van hoe Github te gebruiken is; alle open-source dingen zijn gratis, maar voor een redelijk bedrag (helemaal voor een bedrijf) kan je net wat meer (namespace, privé packages en user management bijv. wie mag publishen etc).

Hé jongens, laten we vanavond plezier hebben! Mijn sexy foto's en contacten hier >> http://dirtytinders.ml/helkiarasi Meld je aan en vind me.

En nu iedereen zo vlug mogelijk overstappen naar deno. Net zoals iedereen overstapte naar gitlab, toen Microsoft github overnam.
Zo krijgt deno wat meer tractie, want het ziet er veel belovend uit.