Package.json-diff: vergelijk npm-manifests online
Plak het oude package.json links, het nieuwe rechts, en zie precies welke dependencies, scripts en engines zijn veranderd. Draait in je browser, niets wordt geüpload.
Wat deze package.json-diff-tool is
Een gratis tool die in de browser draait om twee npm package.json-bestanden naast elkaar te vergelijken. Plak het oude manifest links, het nieuwe rechts, en de verschillen worden teken voor teken gemarkeerd. De tekst verlaat nooit je machine, wat ertoe doet wanneer het manifest bij een privérepo of niet-uitgebracht product hoort.
Het is gebouwd voor het moment dat een Renovate- of Dependabot-PR landt en je moet weten wat er echt veranderd is buiten de versiebumps om. Heeft iemand een script-edit erin gefrommeld? Is het engines-veld van Node 18 naar Node 20 verschoven? Is een peerDependency aangetrokken? GitHubs diff-weergave beantwoordt een deel hiervan, maar twee manifests in een schone tweepaneelview plakken is sneller wanneer je meerdere PR's achter elkaar afstroopt of branches vergelijkt die nog niet gepusht zijn.
Eronder is dit dezelfde JSON-bewuste diff die onze compare-json-pagina aandrijft, met framing en tekst gestemd op npm- en yarn-workflows. Beide manifests worden als JSON geparseerd en mooi uitgevoerd voordat de diff loopt, dus cosmetische whitespace-verschillen vervuilen de markering niet. Als je rauwe tekst-diff nodig hebt voor een niet-JSON-manifestformaat, dekt onze compare-text-tool dat, en compare-yaml behandelt pnpm-lock.yaml.
Hoe de diff echt werkt
Elk paneel wordt als JSON geparseerd. Als parsen lukt, wordt het manifest geherformatteerd met consistente twee-spaties-inspringing en de sleutelvolgorde blijft behouden zoals geschreven. Als parsen faalt (een verdwaalde komma, een ontbrekende accolade, een copy-paste die te weinig tekens pakte) valt de tool terug naar gewone-tekstmodus en vertelt je welke regel brak. Zodra beide kanten geldige JSON zijn, loopt de diff teken voor teken, daarna groepeert een semantische opschoonfase de wijzigingen weer tot leesbare brokken, dus een versiebump van ^18.2.0 naar ^19.0.0 leest als één edit, niet negen tekenedits.
Inserties in het rechterpaneel komen in groen; verwijderingen in het linkerpaneel komen in rood. De twee panelen zijn met scroll aan elkaar vastgemaakt, dus wanneer je een wijziging diep in devDependencies aan één kant vindt, springt de andere kant naar dezelfde sleutel. Omdat de diff op tekstniveau is na het mooi uitvoeren, ziet hij structurele veranderingen zoals een mens ze leest: een verwijderde dependency verdwijnt als regel, een gewijzigd semver-bereik markeert binnenin de waarde, een nieuw script schuift in het scripts-blok op de plek waar je het neerzette.
Wat de tool bewust niet doet: het is geen dependency-resolver. Het zal je niet vertellen welke transitieve pakketten een caret-bereikbump binnentrekt, of een peer voldaan is, of de nieuwe versie een security advisory introduceert. Daarvoor draai je npm install gevolgd door npm audit lokaal, of gebruik je npm met een lockfile-bewuste service zoals Snyk of GitHubs Dependabot-alerts. Deze pagina vertelt je wat de manifesttekst zegt. Het oplossingswerk hoort bij je package manager.
Hoe je een package.json in drie stappen difft
Twee tekstpanelen, één diff. Geen CLI-flags, geen installatiestap, geen patchformaat om te lezen.
- 1
Plak het oude manifest links
Kopieer de vorige versie van package.json uit je editor, uit git show main:package.json, of van een teamgenoot. Plak in het linkerpaneel. De tool parseert het als JSON en voert het mooi uit; als de JSON ongeldig is, toont de editor de parsefout zodat je het snippet kunt repareren voor de diff.
- 2
Plak het nieuwe manifest rechts
Doe hetzelfde met de bijgewerkte versie. Als je een Renovate- of Dependabot-PR doorneemt, is de makkelijkste bron het rauwe bestand uit de PR-branch. Beide bestanden worden mooi uitgevoerd met consistente inspringing, dus cosmetische whitespace-edits verschijnen niet als nepveranderingen in de diff.
- 3
Lees de gemarkeerde verschillen
Verwijderingen tonen als rode doorhalingen links; inserties tonen als groen rechts. Scan eerst de dependency-blokken, controleer dan de scripts-sectie op commando-edits, daarna de engines- en peerDependencies-velden. Versiebumps binnen één waarde markeren de gewijzigde tekens, dus je kunt een patch-bump van een major in één oogopslag onderscheiden.
Wanneer een package.json-diff de juiste keuze is
Een Renovate- of Dependabot-PR nakijken
Een bot opent vijftien PR's in een ochtend. De meeste zijn routine, maar een heeft een script-wijziging erin gefrommeld, of een aangetrokken peerDependency, of een engines-bump die je CI-image breekt. De PR-titel zegt "chore(deps): bump foo from 4.1.0 to 4.2.1" en je vertrouwt op de automatische piloot. Plak de voor-en-na-package.json in de diff en je kunt in vijf seconden verifiëren dat niets anders bewoog. Dit is de meest voorkomende reden waarom JS-engineers naar een manifest-diff grijpen.
Twee branches vergelijken voor het mergen
Jij en een collega hebben beiden package.json aangeraakt op aparte feature-branches. Git zal schoon mergen omdat de edits in verschillende blokken zijn, maar een schone merge betekent geen correcte. Plak de manifests van de twee branches in de diff om een script te spotten dat één branch heeft laten vallen, een dependency die één branch heeft gedowngraded, of een botsing waar beide branches hetzelfde pakket in verschillende versies hebben toegevoegd. Goedkoper dan het te ontdekken nadat CI npm ci tegen het gemerged resultaat draait.
Auditen wat npm install in package-lock.json heeft bevorderd
package.json bewerken is de helft van de wijziging. De andere helft is wat package-lock.json opneemt over de opgeloste boom. Na het draaien van npm install, plak de oude lockfile naast de nieuwe om te zien welke transitieve pakketten meekwamen. Verrassende toevoegingen zijn gewoon wanneer een caret-bereik een nieuwe minor van een diep geneste dependency binnentrok. Voor rauwe lockfile-inspectie behandelt onze compare-json-pagina de grotere bestanden beter; deze pagina is het beste voor het manifest zelf.
Een downgrade controleren na een regressie
Een release gaat live, een bug duikt op, je bisect, en de verdachte zit ergens in de dependency-boom. Plak de package.json van de laatste goede release naast de huidige. Strip onveranderde blokken mentaal eruit en focus op de gemarkeerde versiebereiken. De fix is vaak een downgrade van één bibliotheek naar de in de laatste groene build vastgepinde versie. Zodra je de verdachte vindt, vergrendel hem met een exacte versie (geen caret, geen tilde) tot het upstream-probleem is opgelost.
Je lokale manifest vergelijken met dat van een teamgenoot
Twee engineers, één lastige merge, twee verschillende package.json-bestanden aan het einde van de rebase. De lockfile is nog verwarder. Plak beide manifests naast elkaar om te zien welke sleutels het oneens zijn, los ze dan bewust op in plaats van het resultaat van git merge -X theirs zonder lezen aan te nemen. Dit is ook de juiste tool wanneer je een nieuwe contributor inwerkt wiens npm install een andere boom oppakt dan de jouwe en je een manifest-drift vermoedt.
Pre-publish-review van een bibliotheek's package.json
Voordat je npm publish draait op een bibliotheek, zijn de manifestvelden die ertoe doen anders dan bij een app: main, module, types, exports, files, peerDependencies, engines. Diff het op-het-punt-te-publiceren manifest tegen het laatst gepubliceerde. Een gevallen peerDependencies-vermelding, een veranderde exports-conditie, of een aangetrokken engines-bereik kan consumenten breken op manieren waarvoor npm zelf je niet zal waarschuwen. De Node.js packages-docs zijn de referentie voor wat die velden betekenen.
Package.json-velden die het waard zijn om te kennen
De velden die in echte package.json-diffs opduiken en wat ze betekenen. De moeite waard om door te scannen voor je een Renovate-PR aftikt of twee branches mergt die beide het manifest hebben aangeraakt.
| Topic | What this tool does |
|---|
| dependencies vs devDependencies vs peerDependencies | dependencies worden met je pakket meegeleverd en geïnstalleerd door iedereen die het consumeert. devDependencies worden alleen geïnstalleerd wanneer je npm install draait in de projectroot, nooit voor downstream-consumenten. peerDependencies zijn pakketten waarvan je bibliotheek verwacht dat de host ze levert (typisch React, het testframework, de bundler) en npm 7+ zal ze automatisch installeren tenzij ze conflicteren. Een pakket tussen deze blokken verplaatsen verandert wie de installatiekosten betaalt. |
|---|
| Caret- (^) vs tilde- (~) semver-bereiken | Caret ^1.2.3 staat elke versie toe tot maar zonder 2.0.0; dit is npms standaard en het losseste gangbare bereik. Tilde ~1.2.3 staat alleen patches toe, tot maar zonder 1.3.0. 1.2.x is hetzelfde als tilde. * betekent elke versie (gebruik dit niet in productie). latest wordt opgelost op installatietijd en produceert niet-reproduceerbare builds, dus vermijd het. |
|---|
| Exact pinnen (geen bereikprefix) | "react": "18.2.0" schrijven zonder caret of tilde pint op die exacte versie. Gecombineerd met een lockfile, geeft dit je de meest reproduceerbare installatie tegen de prijs van nooit automatisch security-patches ontvangen. Sommige teams pinnen alles; anderen leunen op de caret-plus-lockfile-combinatie. Er is geen universeel goed antwoord, maar de afweging is meer deterministische builds versus meer verouderde dependencies. |
|---|
| Determinisme van package-lock.json | package-lock.json registreert de exact opgeloste versie van elk pakket in de dependency-boom, transitieven inbegrepen. npm ci installeert vanuit de lockfile en weigert hem te wijzigen; npm install kan hem updaten als een bereik een nieuwere versie toestaat. Voor CI, gebruik altijd npm ci. Voor ontwikkelaars is npm install prima zolang je de resulterende lockfile-wijziging committeert. |
|---|
| workspaces-veld voor monorepos | De workspaces-array vertelt npm om zustermappen als gelinkte pakketten in een monorepo te behandelen. npm install in de root installeert alle workspaces en maakt één gehoiste node_modules-boom. Yarn en pnpm ondersteunen workspaces met hun eigen conventies, en pnpm in het bijzonder hoist minder agressief, wat meer dependency-leak-bugs op installatietijd vangt. |
|---|
| engines-veld | engines.node verklaart de Node.js-versies die je pakket ondersteunt. Standaard waarschuwt npm alleen wanneer de host dit schendt; engine-strict=true in .npmrc maakt er een harde fout van. Het engines-veld bumpen is een breaking change voor consumenten die op oudere Node vastzitten, en het is het soort wijziging dat zich verstopt in een Renovate-"chore"-PR. Lees altijd de engines-diff. |
|---|
| exports-veld voor ES modules | Het exports-veld bestuurt welke paden consumenten uit je pakket kunnen importeren en welke condities (import, require, types, node, browser) naar welke bestanden oplossen. Een vermelding toevoegen of verwijderen is een breaking change voor downstream-code. De Node.js packages-documentatie dekt de oplossingsregels in detail; behandel elke exports-diff als een major-versie-waardige edit tenzij je bewust een nieuw entry point toevoegt. |
|---|
| Bestandsvolgorde binnen package.json | Er is geen afgedwongen volgorde voor top-level sleutels in package.json. Per conventie beginnen de meeste projecten met name, version, description, dan scripts, dan dependencies. Binnen dependency-blokken is alfabetische volgorde op sleutel de de-facto standaard en de meeste package managers sorteren het blok bij opslaan. Een diff die herschikte maar verder identieke vermeldingen toont, is meestal een tooling-verschil, geen echte wijziging. |
|---|
Package.json-diff: veelgestelde vragen
Hoe verschilt dit van npm diff of npm-check-updates?
npm diff is een ingebouwd npm-commando dat twee gepubliceerde versies van een pakket op het registry vergelijkt, inclusief hun tarballs en bronnen. npm-check-updates (ncu) rapporteert welke dependencies in je manifest nieuwere versies beschikbaar hebben. Geen van beide toont je het verschil tussen twee willekeurige package.json-bestanden die je op schijf of in twee branches hebt. Deze tool doet dat. Gebruik ncu om uit te vinden dat je zou moeten upgraden, npm diff om registry-zijde-veranderingen tussen releases te zien, en deze pagina om je eigen voor-en-na-manifest in een naast-elkaar-weergave te lezen.
Audit het beveiliging of controleert het bekende kwetsbaarheden?
Nee. Deze pagina difft alleen de tekst. Het bevraagt het npm-registry niet, de GitHub Advisory Database niet, of welke kwetsbaarheidsservice dan ook. Voor security-audit, draai npm audit tegen een geïnstalleerde boom, gebruik npm audit signatures om pakketherkomst te verifiëren, of leun op Snyk-, Socket-, of Dependabot-alerts. Deze tool is de juiste keuze wanneer je wilt weten wat er in het manifest is veranderd. Het is de verkeerde keuze wanneer je wilt weten of de wijziging veilig is om te verzenden.
Detecteert het transitieve dependency-veranderingen?
Niet vanuit het manifest alleen. package.json somt alleen directe dependencies en hun gevraagde bereiken op. De volledige opgeloste boom, inclusief transitieven, leeft in package-lock.json (of yarn.lock of pnpm-lock.yaml). Om opgeloste bomen te vergelijken, plak beide lockfiles in een diff. Omdat lockfiles groot zijn, behandelt onze compare-json-pagina ze beter dan deze. Voor pnpm-lock.yaml specifiek, gebruik compare-yaml. Deze pagina is geoptimaliseerd voor het manifest.
Hoe vergelijk ik twee package-lock.json-bestanden?
Plak beide lockfiles in de panelen op dezelfde manier als je een manifest zou doen. De tool parseert ze als JSON, voert mooi uit, en difft. Wees je ervan bewust dat lockfiles tot duizenden regels kunnen oplopen, dus de gemarkeerde diff kan lang zijn. Focus eerst op de top-level packages-vermeldingen, dan op de version-velden. Voor bestanden groter dan ongeveer vijfduizend regels past onze compare-json-pagina beter omdat die is opgezet om grote JSON-payloads met dezelfde engine te behandelen.
Wat is het verschil tussen caret- (^) en tilde- (~) bereiken?
Beide zijn semver-bereiken die updates toestaan zonder het manifest handmatig te bewerken. De caret ^1.2.3 staat elke versie toe die het meest linkse niet-nul cijfer niet verandert, dus 1.2.3 tot en met 1.999.999 worden geaccepteerd, maar 2.0.0 niet. De tilde ~1.2.3 is strikter: staat alleen patch-updates toe, dus 1.2.3 tot en met 1.2.999 worden geaccepteerd maar 1.3.0 niet. Caret is de npm-standaard en het lossere bereik; tilde is wat je pakt wanneer een bibliotheek een geschiedenis heeft van breken in minor-releases.
Zijn er groottelimieten voor grote lockfiles?
In de praktijk ja. De diff draait in je browser, dus zeer grote inputs (een lockfile van 20.000 regels uit een monorepo bijvoorbeeld) kunnen de pagina vertragen of de tab laten vastlopen afhankelijk van het geheugen. Voor typische app-manifests en lockfiles tot een paar duizend regels per kant, voltooit de diff praktisch direct. Voor grotere bestanden is onze compare-json-pagina het betere instappunt. Als je regelmatig enorme lockfiles vergelijkt, overweeg om git diff package-lock.json lokaal te draaien en naar een pager te pijpen; die workflow schaalt verder dan welke browsertool dan ook.
Privacy en hoe dit werkt
Je manifests verlaten nooit je browser. De diff, het JSON-parsen, het markeren en het renderen draaien allemaal op je machine. We uploaden de tekst niet, loggen hem niet, en geven hem niet door aan een derde partij. Dit doet er specifiek toe voor proprietary code: het package.json van een niet-uitgebrachte bibliotheek of de lockfile van een privérepo in een clouddienst plakken kan op zichzelf de databehandelingsbeleid van je werkgever schenden, vooral wanneer het manifest interne scoped-pakketten, private-registry-hosts, of namen van producten in ontwikkeling noemt. De claim verifiëren is rechttoe rechtaan. Open de DevTools van je browser, schakel naar het Network-tabblad, plak beide manifests, en kijk. Er zijn geen uitgaande verzoeken wanneer je vergelijkt. Hetzelfde privacy-model geldt over onze andere tools, inclusief compare-json, compare-yaml voor pnpm-lock.yaml, en git-diff-online voor algemene code-review. Voor de onderliggende spec, zie Yarns configuratiereferentie en de npm package.json-docs.