Package.json-diff: jämför npm-manifest online
Klistra in det gamla package.json till vänster, det nya till höger, och se exakt vilka dependencies, scripts och engines som ändrats. Körs i din webbläsare, inget laddas upp.
Vad det här package.json-diff-verktyget är
Ett gratis verktyg som körs i webbläsaren för att jämföra två npm package.json-filer sida vid sida. Klistra in det gamla manifestet till vänster, det nya till höger, och skillnaderna markeras tecken för tecken. Texten lämnar aldrig din maskin, vilket spelar roll när manifestet hör till ett privat repo eller en oreleased produkt.
Det är byggt för stunden då en Renovate- eller Dependabot-PR landar och du behöver veta vad som faktiskt ändrats utöver versions-bumpen. Smög någon in en script-redigering? Flyttades engines-fältet från Node 18 till Node 20? Drogs en peerDependency åt? GitHubs diff-vy svarar på en del av detta, men att klistra in två manifest i en ren tvåpanelvy är snabbare när du går igenom flera PR:er på rad eller jämför grenar som inte är pushade än.
Under huven är detta samma JSON-medvetna diff som driver vår compare-json-sida, med ramverk och text avstämda mot npm- och yarn-flöden. Båda manifesten parsas som JSON och formateras snyggt innan diffen körs, så kosmetiska whitespace-skillnader förorenar inte markeringen. Om du behöver rå text-diff för ett icke-JSON-manifestformat täcker vårt compare-text-verktyg det, och compare-yaml hanterar pnpm-lock.yaml.
Hur diffen faktiskt fungerar
Varje panel parsas som JSON. Om parsningen lyckas formateras manifestet om med konsekvent två-mellanslag-indrag och nyckelordningen bevaras som skriven. Om parsningen misslyckas (ett vilset komma, en saknad klammer, en copy-paste som tog för få tecken) faller verktyget tillbaka till klartextläge och säger vilken rad som bröts. När båda sidor är giltig JSON körs diffen tecken för tecken, sedan grupperar en semantisk uppstädning ändringarna tillbaka till läsbara bitar, så ett versionssprång från ^18.2.0 till ^19.0.0 läses som en redigering, inte nio teckenredigeringar.
Insättningar i höger panel renderas i grönt; raderingar i vänster panel renderas i rött. De två panelerna är scroll-låsta tillsammans, så när du hittar en ändring djupt inne i devDependencies på ena sidan hoppar den andra till samma nyckel. Eftersom diffen är på textnivå efter snygg formatering ser den strukturella ändringar som en människa läser dem: ett borttaget beroende försvinner som rad, ett ändrat semver-intervall markeras inuti värdet, ett nytt script glider in i scripts-blocket på positionen där du satte det.
Vad verktyget medvetet inte gör: det är inte en beroendelösare. Det säger inte vilka transitiva paket en caret-intervall-bump drar in, om en peer är uppfylld, eller om den nya versionen introducerar en säkerhetsvarning. För det, kör npm install följt av npm audit lokalt, eller använd npm med en lockfile-medveten tjänst som Snyk eller GitHubs Dependabot-aviseringar. Den här sidan säger vad manifesttexten säger. Lösningsarbetet hör till din pakethanterare.
Hur man diffar en package.json i tre steg
Två textpaneler, en diff. Inga CLI-flaggor, inget installationssteg, inget patch-format att läsa.
- 1
Klistra in det gamla manifestet till vänster
Kopiera den tidigare versionen av package.json från din editor, från git show main:package.json, eller från en lagkamrat. Klistra in i vänster panel. Verktyget parsar det som JSON och formaterar snyggt; om JSON är ogiltig visar editorn parse-felet så att du kan fixa snippet:en innan diffen.
- 2
Klistra in det nya manifestet till höger
Gör detsamma med den uppdaterade versionen. Om du granskar en Renovate- eller Dependabot-PR är den lättaste källan rå-filen från PR-grenen. Båda filerna formateras snyggt med konsekvent indrag, så kosmetiska whitespace-redigeringar dyker inte upp som falska ändringar i diffen.
- 3
Läs de markerade skillnaderna
Raderingar visas som röda överstrykningar till vänster; insättningar visas som gröna till höger. Skanna beroendeblocken först, kolla sedan scripts-sektionen för kommandoredigeringar, sedan engines- och peerDependencies-fälten. Versions-bumpar inom ett enskilt värde markerar de ändrade tecknen, så du kan skilja en patch-bump från en major med en blick.
När en package.json-diff är rätt val
Granska en Renovate- eller Dependabot-PR
En bot öppnar femton PR:er på en förmiddag. De flesta är rutin, men en smög in en script-ändring, eller en åtdragen peerDependency, eller en engines-bump som bryter din CI-image. PR-titeln säger "chore(deps): bump foo from 4.1.0 to 4.2.1" och du litar på autopilot. Klistra in före-och-efter-package.json i diffen och du kan verifiera på fem sekunder att inget annat rörde sig. Detta är den enskilt vanligaste anledningen att JS-ingenjörer sträcker sig efter en manifest-diff.
Jämföra två grenar före merge
Du och en kollega rörde båda package.json på separata feature-grenar. Git mergar rent eftersom redigeringarna är i olika block, men en ren merge betyder inte en korrekt. Klistra in de två grenarnas manifest i diffen för att hitta ett script som en gren tappade, ett beroende som en gren nedgraderat, eller en krock där båda grenarna lade till samma paket i olika versioner. Billigare än att upptäcka det efter att CI kört npm ci mot det mergade resultatet.
Granska vad npm install befordrade i package-lock.json
Att redigera package.json är halva ändringen. Den andra halvan är vad package-lock.json registrerar om det lösta trädet. Efter att du kört npm install, klistra in den gamla lockfilen bredvid den nya för att se vilka transitiva paket som följde med. Överraskningstillägg är vanliga när ett caret-intervall drog in en ny minor av ett djupt nästlat beroende. För rå lockfile-inspektion hanterar vår compare-json-sida de större filerna bättre; den här sidan är bäst för manifestet självt.
Kolla en nedgradering efter en regression
En release går ut, en bugg dyker upp, du bisectar, och den misstänkte är någonstans i beroendeträdet. Klistra in package.json från den senaste bra releasen bredvid den nuvarande. Stryk oförändrade block mentalt och fokusera på de markerade versionsintervallen. Fixen är ofta en nedgradering av ett bibliotek till versionen som var pinned i den senaste gröna byggen. När du hittat den misstänkte, lås den med en exakt version (ingen caret, ingen tilde) tills uppströmsfrågan är löst.
Jämföra ditt lokala manifest med en lagkamrats
Två ingenjörer, en knepig merge, två olika package.json-filer i slutet av rebasen. Lockfilen är ännu mer förvirrad. Klistra in båda manifesten sida vid sida för att se vilka nycklar som inte stämmer överens, lös dem sedan medvetet istället för att acceptera resultatet av git merge -X theirs utan att läsa. Detta är också rätt verktyg när du onboardar en ny bidragsgivare vars npm install hämtar ett annat träd än ditt och du misstänker en manifest-drift.
Pre-publish-granskning av ett biblioteks package.json
Innan du kör npm publish på ett bibliotek är manifestfälten som spelar roll annorlunda än för en app: main, module, types, exports, files, peerDependencies, engines. Diffa det manifest som ska publiceras mot det senast publicerade. En tappad peerDependencies-post, ett ändrat exports-villkor, eller ett åtdragen engines-intervall kan bryta konsumenter på sätt som npm självt inte varnar för. Node.js packages-dokumentation är referensen för vad de fälten betyder.
Package.json-fält värda att känna till
Fälten som dyker upp i riktiga package.json-diffar och vad de betyder. Värt att skanna innan du godkänner en Renovate-PR eller mergar två grenar som båda rört manifestet.
| Topic | What this tool does |
|---|
| dependencies vs devDependencies vs peerDependencies | dependencies levereras med ditt paket och installeras av alla som konsumerar det. devDependencies installeras bara när du kör npm install i projektets rot, aldrig för nedströmskonsumenter. peerDependencies är paket som ditt bibliotek förväntar sig att värden tillhandahåller (typiskt React, testramverket, bundlern) och npm 7+ installerar dem automatiskt om de inte hamnar i konflikt. Att flytta ett paket mellan dessa block ändrar vem som betalar installationskostnaden. |
|---|
| Caret- (^) vs tilde- (~) semver-intervall | Caret ^1.2.3 tillåter vilken version som helst upp till men inte inklusive 2.0.0; detta är npms standard och det lösaste vanliga intervallet. Tilde ~1.2.3 tillåter bara patchar, upp till men inte inklusive 1.3.0. 1.2.x är samma som tilde. * betyder vilken version som helst (använd inte detta i produktion). latest löses vid installationstid och producerar icke-reproducerbara byggen, så undvik det. |
|---|
| Exakt pinning (inget intervall-prefix) | Att skriva "react": "18.2.0" utan caret eller tilde pinnar till den exakta versionen. Kombinerat med en lockfile ger detta dig den mest reproducerbara installationen till priset av att aldrig få säkerhetspatchar automatiskt. Vissa team pinnar allt; andra litar på caret-plus-lockfile-kombinationen. Det finns inget universellt rätt svar, men avvägningen är mer deterministiska byggen mot mer föråldrade beroenden. |
|---|
| package-lock.json-determinism | package-lock.json registrerar den exakt lösta versionen av varje paket i beroendeträdet, inklusive transitiva. npm ci installerar från lockfilen och vägrar modifiera den; npm install kan uppdatera den om ett intervall tillåter en nyare version. För CI, använd alltid npm ci. För utvecklare är npm install okej så länge du commitar den resulterande lockfile-ändringen. |
|---|
| workspaces-fält för monorepon | workspaces-arrayen säger åt npm att behandla syskonkataloger som länkade paket i en monorepo. npm install i roten installerar alla workspaces och skapar ett enda hoistat node_modules-träd. Yarn och pnpm stöder workspaces med sina egna konventioner, och pnpm i synnerhet hoistar mindre aggressivt, vilket fångar fler beroende-läckage-buggar vid installationstid. |
|---|
| engines-fält | engines.node deklarerar vilka Node.js-versioner ditt paket stödjer. Som standard varnar npm bara när värden bryter mot detta; engine-strict=true i .npmrc gör det till ett hårt fel. Att bumpa engines-fältet är en brytande ändring för konsumenter som sitter fast på äldre Node, och det är den sortens ändring som gömmer sig i en Renovate-"chore"-PR. Läs alltid engines-diffen. |
|---|
| exports-fält för ES modules | exports-fältet styr vilka sökvägar konsumenter kan importera från ditt paket och vilka villkor (import, require, types, node, browser) som löses till vilka filer. Att lägga till eller ta bort en post är en brytande ändring för nedströmskod. Node.js packages-dokumentationen täcker upplösningsreglerna i detalj; behandla varje exports-diff som en major-versionsvärd redigering om du inte medvetet lägger till en ny ingångspunkt. |
|---|
| Filordning inom package.json | Det finns ingen tvingad ordning för toppnivå-nycklar i package.json. Som konvention börjar de flesta projekt med name, version, description, sedan scripts, sedan beroenden. Inom beroendeblock är alfabetisk ordning per nyckel de facto-standard och de flesta pakethanterare sorterar blocket vid sparning. En diff som visar omsorterade men annars identiska poster är vanligtvis en verktygsskillnad, inte en verklig ändring. |
|---|
Package.json-diff: vanliga frågor
Hur skiljer sig detta från npm diff eller npm-check-updates?
npm diff är ett inbyggt npm-kommando som jämför två publicerade versioner av ett paket på registry, inklusive deras tarballs och källor. npm-check-updates (ncu) rapporterar vilka beroenden i ditt manifest som har nyare versioner tillgängliga. Ingen visar dig skillnaden mellan två godtyckliga package.json-filer du har på disk eller i två grenar. Det här verktyget gör det. Använd ncu för att ta reda på att du borde uppgradera, npm diff för att se registry-sidans ändringar mellan releaser, och den här sidan för att läsa ditt eget före-och-efter-manifest i en sida-vid-sida-vy.
Granskar det säkerhet eller kollar kända sårbarheter?
Nej. Den här sidan diffar bara texten. Den frågar inte npm-registry, GitHub Advisory Database eller någon sårbarhetstjänst. För säkerhetsgranskning, kör npm audit mot ett installerat träd, använd npm audit signatures för att verifiera paketursprung, eller luta dig mot Snyk-, Socket- eller Dependabot-aviseringar. Det här verktyget är rätt val när du vill veta vad som ändrats i manifestet. Det är fel val när du vill veta om ändringen är säker att skicka.
Upptäcker det transitiva beroendeändringar?
Inte från manifestet ensamt. package.json listar bara direkta beroenden och deras begärda intervall. Det fullständiga lösta trädet, inklusive transitiva, lever i package-lock.json (eller yarn.lock eller pnpm-lock.yaml). För att jämföra lösta träd, klistra in båda lockfilerna i en diff. Eftersom lockfiler är stora hanterar vår compare-json-sida dem bättre än den här. För pnpm-lock.yaml specifikt, använd compare-yaml. Den här sidan är optimerad för manifestet.
Hur jämför jag två package-lock.json-filer?
Klistra in båda lockfilerna i panelerna på samma sätt som du skulle göra med ett manifest. Verktyget parsar dem som JSON, formaterar snyggt och diffar. Var medveten om att lockfiler kan gå upp till tusentals rader, så den markerade diffen kan vara lång. Fokusera på toppnivå-packages-poster först, sedan på version-fälten. För filer större än ungefär femtusen rader passar vår compare-json-sida bättre eftersom den är inställd för att hantera stora JSON-payloads med samma motor.
Vad är skillnaden mellan caret- (^) och tilde- (~) intervall?
Båda är semver-intervall som tillåter uppdateringar utan att redigera manifestet manuellt. Caret ^1.2.3 tillåter vilken version som helst som inte ändrar den vänstraste icke-noll-siffran, så 1.2.3 till 1.999.999 accepteras, men 2.0.0 inte. Tilde ~1.2.3 är striktare: tillåter bara patch-uppdateringar, så 1.2.3 till 1.2.999 accepteras men 1.3.0 inte. Caret är npms standard och det lösare intervallet; tilde är vad du sträcker dig efter när ett bibliotek har en historia av att bryta i minor-releaser.
Finns storleksgränser för stora lockfiler?
Praktiskt sett ja. Diffen körs i din webbläsare, så väldigt stora indata (en 20 000-radig lockfile från en monorepo, till exempel) kan sakta ner sidan eller stoppa fliken beroende på minne. För typiska app-manifest och lockfiler upp till några tusen rader per sida slutförs diffen i praktiken omedelbart. För större filer är vår compare-json-sida den bättre ingångspunkten. Om du regelbundet jämför enorma lockfiler, överväg att köra git diff package-lock.json lokalt och pipa till en pager; det flödet skalar längre än något webbläsarverktyg.
Integritet och hur detta fungerar
Dina manifest lämnar aldrig din webbläsare. Diffen, JSON-parsningen, markeringen och renderingen körs alla på din maskin. Vi laddar inte upp texten, loggar den inte, och skickar den inte till någon tredjepartstjänst. Detta spelar specifikt roll för proprietär kod: att klistra in package.json från ett oreleased bibliotek eller ett privat repos lockfile i en molntjänst kan i sig bryta mot din arbetsgivares datahanteringspolicy, särskilt när manifestet namnger interna scoped-paket, privata registry-värdar, eller produktnamn under utveckling. Att verifiera påståendet är enkelt. Öppna webbläsarens DevTools, byt till Network-fliken, klistra in båda manifesten, och titta. Det finns inga utgående förfrågningar när du jämför. Samma integritetsmodell håller över våra andra verktyg, inklusive compare-json, compare-yaml för pnpm-lock.yaml, och git-diff-online för allmän kodgranskning. För den underliggande specen, se Yarns konfigurationsreferens och npm:s package.json-dokumentation.