Voor npm-aanpassing node_modules boom of elke actie package.json wordt automatisch een package-lock.json gegenereerd. Het beschrijft de exacte boom die wordt gegenereerd, zodat latere installaties dezelfde boom kunnen genereren, ongeacht intermediaire afhankelijkheidsupdates.
Dit bestand is bedoeld om naar de broncoderepository te worden gestuurd en is beschikbaar voor verschillende doeleinden:
Beschrijft een enkele representatie van de afhankelijkheidsboom om te garanderen dat teamgenoten, implementaties en continue integratie ervoor zorgen dat exact dezelfde afhankelijkheden worden geïnstalleerd.
Bied gebruikers een tool om naar een vorige node_modules-toestand te "doorgaan" zonder de directory zelf te hoeven committen.
Beter zicht op boomwijzigingen door leesbare verschillen in bronbeheer.
En optimaliseer het installatieproces door npm toe te staan de dubbele metadata-resolutie van eerder geïnstalleerde pakketten over te slaan.
Een belangrijk detail over package-lock.json is dat het niet kan worden uitgebracht en genegeerd zal worden als het ergens buiten het toppakket wordt gevonden. Het deelt het formaat met npm-shrinkwrap.json, het is in feite hetzelfde bestand maar maakt publicatie mogelijk. Dit wordt niet aanbevolen tenzij je een CLI-tool deployt of anderszins het releaseproces gebruikt om een productiepakket te maken.
Als zowel package-lock.json als npm-shrinkwrap.json in de rootmap van een pakket bestaan, wordt package-lock.json volledig genegeerd.
Originele link: https://docs.npmjs.com/files/package-lock.json
Sinds de release van npm 5.x is de rol van de 5.6.0-lock vele malen veranderd, en nu zitten veel kleine witte teksten op het internet vast in de vorige documentvertaling.
Ik heb geüpdatet van npm3.x naar npm5, maar ontdekte dat het fenomeen bij het uitvoeren van 'npm i' niet consistent was met het populaire wetenschappelijke artikel op het internet.
Er wordt vermeld dat ongeacht hoe package.json bestand wordt aangepast, als npm i herhaaldelijk wordt uitgevoerd, npm wordt gedownload volgens de versie-informatie die in het lock-bestand wordt beschreven.
Er wordt ook vermeld dat bij het herhalen van npm i, npm de lock-informatie negeert en de updatemodule downloadt volgens de Semantic versioning-versie-informatie van het pakket in de package.json (lock lijkt nutteloos).
**Volgens de informatie zijn de regels van npm i drie keer gewijzigd sinds de release van npm 5.0. **
1. npm 5.0.x versie, ongeacht hoe de package.json verandert, wordt npm I gedownload volgens het lock-bestand
package-lock.json bestand dat niet wordt bijgewerkt nadat package.json bestand is gewijzigd · Nummer #16866 · NPM/NPM-https://github.com/npm/npm/issues/16866
Dit probleem klaagt over dit probleem, natuurlijk heb ik de package.json handmatig aangepast, waarom geef je me geen upgradepakket! En dan leidt het tot het probleem van 5.1.0...
2. Na versie 5.1.0 negeert npm-installatie het lock-bestand om de nieuwste npm te downloaden
Toen bracht iemand dit probleem ter sprake: waarom wordt package-lock genegeerd? · Nummer #17979 · NPM/NPM https://github.com/npm/npm/issues/17979
De klacht ontwikkelde zich uiteindelijk tot de regels na versie 5.4.2.
3. Waarom wordt pakketvergrendeling genegeerd na versie 5.4.2? · Nummer #17979 · NPM/NPM https://github.com/npm/npm/issues/17979
Grofweg gesproken, als de package.json wordt gewijzigd en de package.json verschilt van het lock-bestand, zal npm het nieuwste pakket downloaden op basis van het versienummer en de semantische betekenis van het pakket bij het uitvoeren van 'npm i', en het updaten naar lock.
Als beide in dezelfde staat zitten, zal ik npm I uitvoeren volgens de lock, ongeacht of de daadwerkelijke pakketversie nieuw is of niet.
|
Geplaatst op 13-12-2017 13:17:45
|
|
|
