Package.json-diff: sammenlign npm-manifester online
Indsæt det gamle package.json til venstre, det nye til højre, og se præcis hvilke dependencies, scripts og engines der er ændret. Kører i din browser, intet uploades.
Hvad dette package.json-diff-værktøj er
Et gratis værktøj der kører i browseren til at sammenligne to npm package.json-filer side om side. Indsæt det gamle manifest til venstre, det nye til højre, og forskellene fremhæves tegn for tegn. Teksten forlader aldrig din maskine, hvilket betyder noget når manifestet hører til et privat repo eller et ikke-udgivet produkt.
Det er bygget til det øjeblik en Renovate- eller Dependabot-PR lander, og du har brug for at vide hvad der faktisk ændrede sig ud over versions-bumpene. Smuglede nogen en script-redigering ind? Flyttede engines-feltet sig fra Node 18 til Node 20? Blev en peerDependency strammet? GitHubs diff-visning besvarer en del af dette, men at indsætte to manifester i en ren tovinduesvisning er hurtigere når du skanner flere PR'er i træk eller sammenligner grene der ikke er pushet endnu.
Indenunder er dette samme JSON-bevidste diff der driver vores compare-json-side, med rammer og tekst tunet til npm- og yarn-flows. Begge manifester parses som JSON og pretty-printes før diffen kører, så kosmetiske whitespace-forskelle ikke forurener fremhævelsen. Hvis du har brug for rå tekst-diff til et ikke-JSON-manifestformat, dækker vores compare-text-værktøj det, og compare-yaml håndterer pnpm-lock.yaml.
Hvordan diffen faktisk virker
Hvert vindue parses som JSON. Hvis parsingen lykkes, omformateres manifestet med konsistent to-mellemrums-indrykning og nøglerækkefølgen bevares som skrevet. Hvis parsingen fejler (et forvildet komma, en manglende klamme, en kopi-indsæt der greb for få tegn) falder værktøjet tilbage til klartekst-tilstand og fortæller hvilken linje der knækkede. Når begge sider er gyldig JSON, kører diffen tegn for tegn, derefter grupperer en semantisk oprydningsfase ændringerne tilbage til læselige bidder, så et versionsbump fra ^18.2.0 til ^19.0.0 læses som én redigering, ikke ni tegn-redigeringer.
Indsættelser i højre vindue rendres i grønt; sletninger i venstre vindue rendres i rødt. De to vinduer er scroll-låst sammen, så når du finder en ændring dybt inde i devDependencies på den ene side, hopper den anden til samme nøgle. Fordi diffen er på tekstniveau efter pretty-print, ser den strukturelle ændringer som et menneske læser dem: en fjernet afhængighed forsvinder som en linje, et ændret semver-interval fremhæves inde i værdien, et nyt script glider ind i scripts-blokken på den position du satte det.
Hvad værktøjet bevidst ikke gør: det er ikke en afhængighedsløser. Det vil ikke fortælle dig hvilke transitive pakker et caret-interval-bump trækker ind, om en peer er opfyldt, eller om den nye version introducerer en sikkerhedsadvarsel. Til det, kør npm install efterfulgt af npm audit lokalt, eller brug npm med en lockfile-bevidst tjeneste som Snyk eller GitHubs Dependabot-advarsler. Denne side fortæller dig hvad manifestteksten siger. Opløsningsarbejdet hører til din pakkemanager.
Hvordan man differ en package.json i tre trin
To tekstvinduer, én diff. Ingen CLI-flag, intet installationstrin, intet patch-format at læse.
- 1
Indsæt det gamle manifest til venstre
Kopier den tidligere version af package.json fra din editor, fra git show main:package.json, eller fra en holdkammerat. Indsæt i venstre vindue. Værktøjet parser det som JSON og pretty-printer; hvis JSON er ugyldig, viser editoren parse-fejlen så du kan fikse uddraget før diffen.
- 2
Indsæt det nye manifest til højre
Gør det samme med den opdaterede version. Hvis du gennemgår en Renovate- eller Dependabot-PR, er den nemmeste kilde rå-filen fra PR-grenen. Begge filer pretty-printes med konsistent indrykning, så kosmetiske whitespace-redigeringer dukker ikke op som falske ændringer i diffen.
- 3
Læs de fremhævede forskelle
Sletninger vises som røde overstregninger til venstre; indsættelser vises som grønne til højre. Skan afhængighedsblokkene først, tjek så scripts-sektionen for kommando-redigeringer, derefter engines- og peerDependencies-felterne. Versionsbumps inden for en enkelt værdi fremhæver de ændrede tegn, så du kan skelne et patch-bump fra et major med et blik.
Hvornår en package.json-diff er det rigtige valg
Gennemgå en Renovate- eller Dependabot-PR
En bot åbner femten PR'er på en formiddag. De fleste er rutine, men én smuglede en script-ændring ind, eller en strammet peerDependency, eller et engines-bump der bryder dit CI-image. PR-titlen siger "chore(deps): bump foo from 4.1.0 to 4.2.1" og du stoler på autopiloten. Indsæt før-og-efter-package.json i diffen og du kan verificere på fem sekunder at intet andet flyttede sig. Dette er den enkeltvis hyppigste grund til at JS-ingeniører rækker efter en manifest-diff.
Sammenligne to grene før merge
Du og en kollega rørte begge ved package.json på separate feature-grene. Git merger rent fordi redigeringerne er i forskellige blokke, men en ren merge betyder ikke en korrekt. Indsæt de to grenes manifester i diffen for at fange et script som én gren droppede, en afhængighed som én gren nedgraderede, eller en kollision hvor begge grene tilføjede den samme pakke i forskellige versioner. Billigere end at opdage det efter CI har kørt npm ci mod det mergede resultat.
Auditere hvad npm install forfremmede i package-lock.json
At redigere package.json er halvdelen af ændringen. Den anden halvdel er hvad package-lock.json registrerer om det opløste træ. Efter at have kørt npm install, indsæt den gamle lockfile ved siden af den nye for at se hvilke transitive pakker der kom med på turen. Overraskelsestilføjelser er almindelige når et caret-interval trak en ny minor af en dybt indlejret afhængighed ind. Til rå lockfile-inspektion håndterer vores compare-json-side de større filer bedre; denne side er bedst til selve manifestet.
Tjekke en nedgradering efter en regression
En udgivelse går ud, en bug dukker op, du bisecter, og den mistænkte er et eller andet sted i afhængighedstræet. Indsæt package.json fra den sidste gode udgivelse ved siden af den nuværende. Stryg uændrede blokke mentalt og fokusér på de fremhævede versionsintervaller. Rettelsen er ofte en nedgradering af ét bibliotek til den version der var pinned i den sidste grønne build. Når du har fundet den mistænkte, lås den med en eksakt version (ingen caret, ingen tilde) indtil opstrømsproblemet er løst.
Sammenligne dit lokale manifest med en holdkammerats
To ingeniører, én besværlig merge, to forskellige package.json-filer ved slutningen af rebasen. Lockfilen er endnu mere forvirret. Indsæt begge manifester side om side for at se hvilke nøgler der er uenige, løs dem så bevidst i stedet for at acceptere resultatet af git merge -X theirs uden at læse. Dette er også det rigtige værktøj når du onboarder en ny bidragyder hvis npm install samler et andet træ end dit, og du mistænker en manifest-drift.
Pre-publish-gennemgang af et biblioteks package.json
Før du kører npm publish på et bibliotek, er manifestfelterne der betyder noget anderledes end for en app: main, module, types, exports, files, peerDependencies, engines. Diff det manifest der er ved at blive udgivet mod det sidst udgivne. En droppet peerDependencies-post, en ændret exports-betingelse, eller et strammet engines-interval kan bryde forbrugere på måder som npm selv ikke advarer dig om. Node.js packages docs er referencen for hvad de felter betyder.
Package.json-felter værd at kende
Felterne der dukker op i rigtige package.json-diffs og hvad de betyder. Værd at skanne før du godkender en Renovate-PR eller merger to grene der begge rørte ved manifestet.
| Topic | What this tool does |
|---|
| dependencies vs devDependencies vs peerDependencies | dependencies følger med din pakke og installeres af enhver der forbruger den. devDependencies installeres kun når du kører npm install i projektets rod, aldrig for nedstrøms-forbrugere. peerDependencies er pakker som dit bibliotek forventer at værten leverer (typisk React, testrammeværket, bundleren) og npm 7+ vil installere dem automatisk medmindre de er i konflikt. At flytte en pakke mellem disse blokke ændrer hvem der betaler installationsomkostningen. |
|---|
| Caret- (^) vs tilde- (~) semver-intervaller | Caret ^1.2.3 tillader enhver version op til men ikke inklusive 2.0.0; dette er npms standard og det løseste almindelige interval. Tilde ~1.2.3 tillader kun patches, op til men ikke inklusive 1.3.0. 1.2.x er det samme som tilde. * betyder enhver version (brug ikke dette i produktion). latest opløses ved installationstid og producerer ikke-reproducerbare builds, så undgå det. |
|---|
| Eksakt pinning (intet interval-præfiks) | At skrive "react": "18.2.0" uden caret eller tilde pinner til den eksakte version. Kombineret med en lockfile giver dette dig den mest reproducerbare installation til prisen af aldrig at modtage sikkerhedspatches automatisk. Nogle hold pinner alt; andre stoler på caret-plus-lockfile-kombinationen. Der er ikke noget universelt rigtigt svar, men afvejningen er mere deterministiske builds mod mere forældede afhængigheder. |
|---|
| package-lock.json-determinisme | package-lock.json registrerer den eksakte opløste version af hver pakke i afhængighedstræet, inklusive transitive. npm ci installerer fra lockfilen og nægter at modificere den; npm install kan opdatere den hvis et interval tillader en nyere version. Til CI, brug altid npm ci. Til udviklere er npm install okay så længe du commiter den resulterende lockfile-ændring. |
|---|
| workspaces-felt til monorepoer | workspaces-arrayet siger til npm at behandle søsterkataloger som linkede pakker i et monorepo. npm install i roden installerer alle workspaces og opretter et enkelt hoistet node_modules-træ. Yarn og pnpm understøtter workspaces med deres egne konventioner, og pnpm i særdeleshed hoister mindre aggressivt, hvilket fanger flere afhængigheds-lækage-bugs ved installationstid. |
|---|
| engines-felt | engines.node erklærer de Node.js-versioner din pakke understøtter. Som standard advarer npm kun når værten overtræder dette; engine-strict=true i .npmrc gør det til en hård fejl. At bumpe engines-feltet er en brydende ændring for forbrugere der sidder fast på ældre Node, og det er den slags ændring der gemmer sig inde i en Renovate-"chore"-PR. Læs altid engines-diffen. |
|---|
| exports-felt til ES modules | exports-feltet styrer hvilke stier forbrugere kan importere fra din pakke og hvilke betingelser (import, require, types, node, browser) der opløses til hvilke filer. At tilføje eller fjerne en post er en brydende ændring for nedstrømskode. Node.js packages-dokumentationen dækker opløsningsreglerne i detaljer; behandl enhver exports-diff som en major-versions-værdig redigering medmindre du bevidst tilføjer et nyt indgangspunkt. |
|---|
| Filrækkefølge inde i package.json | Der er ingen påtvunget rækkefølge for top-niveau-nøgler i package.json. Konventionelt starter de fleste projekter med name, version, description, så scripts, så afhængigheder. Inden for afhængighedsblokke er alfabetisk rækkefølge per nøgle de facto-standarden og de fleste pakkemanagere sorterer blokken ved gemning. En diff der viser omarrangerede men ellers identiske poster, er normalt en værktøjsforskel, ikke en reel ændring. |
|---|
Package.json-diff: ofte stillede spørgsmål
Hvordan adskiller dette sig fra npm diff eller npm-check-updates?
npm diff er en indbygget npm-kommando der sammenligner to udgivne versioner af en pakke på registry, inklusive deres tarballs og kilder. npm-check-updates (ncu) rapporterer hvilke afhængigheder i dit manifest der har nyere versioner tilgængelige. Ingen af dem viser dig forskellen mellem to vilkårlige package.json-filer du har på disk eller i to grene. Dette værktøj gør det. Brug ncu til at finde ud af at du burde opgradere, npm diff til at se registry-side-ændringer mellem udgivelser, og denne side til at læse dit eget før-og-efter-manifest i en side-om-side-visning.
Auditerer det sikkerhed eller tjekker for kendte sårbarheder?
Nej. Denne side differ kun teksten. Den spørger ikke npm-registry, GitHub Advisory Database, eller nogen sårbarhedstjeneste. Til sikkerhedsaudit, kør npm audit mod et installeret træ, brug npm audit signatures til at verificere pakkeoprindelse, eller læn dig op ad Snyk-, Socket- eller Dependabot-advarsler. Dette værktøj er det rigtige valg når du vil vide hvad der ændrede sig i manifestet. Det er det forkerte valg når du vil vide om ændringen er sikker at sende.
Opdager det transitive afhængighedsændringer?
Ikke fra manifestet alene. package.json lister kun direkte afhængigheder og deres anmodede intervaller. Det fulde opløste træ, inklusive transitive, lever i package-lock.json (eller yarn.lock eller pnpm-lock.yaml). For at sammenligne opløste træer, indsæt begge lockfiler i en diff. Fordi lockfiler er store, håndterer vores compare-json-side dem bedre end denne. For pnpm-lock.yaml specifikt, brug compare-yaml. Denne side er optimeret til manifestet.
Hvordan sammenligner jeg to package-lock.json-filer?
Indsæt begge lockfiler i vinduerne på samme måde som du ville et manifest. Værktøjet parser dem som JSON, pretty-printer og differ. Vær opmærksom på at lockfiler kan løbe op i tusinder af linjer, så den fremhævede diff kan være lang. Fokuser på top-niveau-packages-poster først, så på version-felterne. Til filer større end omtrent fem tusind linjer passer vores compare-json-side bedre fordi den er sat op til at håndtere store JSON-payloads med samme motor.
Hvad er forskellen mellem caret- (^) og tilde- (~) intervaller?
Begge er semver-intervaller der tillader opdateringer uden manuelt at redigere manifestet. Caret ^1.2.3 tillader enhver version der ikke ændrer det venstreste ikke-nul-ciffer, så 1.2.3 til 1.999.999 accepteres, men 2.0.0 ikke. Tilde ~1.2.3 er strengere: tillader kun patch-opdateringer, så 1.2.3 til 1.2.999 accepteres men 1.3.0 ikke. Caret er npms standard og det løsere interval; tilde er hvad du rækker efter når et bibliotek har en historie med at bryde i minor-udgivelser.
Er der størrelsesgrænser for store lockfiler?
Praktisk set ja. Diffen kører i din browser, så meget store input (en 20.000-linjers lockfile fra et monorepo, for eksempel) kan sløve siden eller stoppe fanen afhængigt af hukommelse. Til typiske app-manifester og lockfiler op til et par tusind linjer per side gennemfører diffen praktisk talt øjeblikkeligt. Til større filer er vores compare-json-side det bedre indgangspunkt. Hvis du regelmæssigt sammenligner enorme lockfiler, overvej at køre git diff package-lock.json lokalt og pipe til en pager; det flow skalerer længere end nogen browser-værktøj.
Privatliv og hvordan dette virker
Dine manifester forlader aldrig din browser. Diffen, JSON-parsningen, fremhævelsen og renderingen kører alt sammen på din maskine. Vi uploader ikke teksten, logger den ikke, og videregiver den ikke til nogen tredjepartstjeneste. Dette betyder noget specifikt for proprietær kode: at indsætte package.json fra et ikke-udgivet bibliotek eller et privat repos lockfile i en cloud-tjeneste kan i sig selv overtræde din arbejdsgivers datahåndteringspolitik, især når manifestet navngiver interne scoped-pakker, private registry-værter, eller produktnavne under udvikling. At verificere påstanden er ligetil. Åbn browserens DevTools, skift til Network-fanen, indsæt begge manifester og kig. Der er ingen udgående forespørgsler når du sammenligner. Samme privatlivsmodel holder på tværs af vores andre værktøjer, inklusive compare-json, compare-yaml til pnpm-lock.yaml, og git-diff-online til generel kodegennemgang. For den underliggende spec, se Yarns konfigurationsreference og npm package.json-dokumentation.