npm ci: återskapa AI-projektets beroenden

1. Inventera runtime, manifest, lockfil och konfiguration

En AI-byggd app som startar på upphovspersonens dator är en bra början. Vid övertagandet behöver du ett prov som någon annan kan upprepa från en bestämd commit. Den här guiden gäller Node-projekt som använder npm och en incheckad package-lock.json. Om projektet använder en annan pakethanterare, välj dess installationsmetod innan du fortsätter. Blanda inte in en ny lockfil bara för att kommandot ska fungera.

Börja i projektets rot. Läs package.json och kontrollera vilka scripts som faktiskt finns för bygge och test. Notera filerna som beskriver runtime, exempelvis .nvmrc, samt projektets .npmrc. Kör följande kommandon och skriv resultaten i ett installationsprotokoll. Exemplen använder PowerShell; byt sökvägarna mot dina egna och kontrollera varje exitkod innan du går vidare.

node --version
npm --version
node -p "process.platform + ' ' + process.arch"
git rev-parse HEAD
git status --short
npm config get registry
npm config get legacy-peer-deps
npm config get install-links
npm config get omit
npm config get ignore-scripts
npm run

Skriv också ned operativsystemets version och om NODE_ENV är satt. Spara relevanta konfigurationsvärden, men kopiera inte autentiseringstoken eller hela privata konfigurationsfiler till en delad logg. En projektfil räcker inte som miljöbeskrivning: npm får inställningar från kommandoraden, miljövariabler och flera npmrc-filer enligt dokumentationen om .npmrc. Anteckna därför även avvikelser från projektets avsedda inställningar.

Lockfilen beskriver det upplösta beroendeträdet och är avsedd att versionshanteras, enligt npm:s beskrivning av package-lock.json. Den är underlag för installationsprovet. Den är inte ensam ett bevis på identiska byggartefakter: vår slutsats begränsas till noterad runtime, plattform, konfiguration och körda scripts. Läs granskningen av beroenden som AI föreslår om frågan i stället är vilka paket du bör acceptera.

2. Installera i en separat ren arbetskopia

Välj en commit som innehåller det du vill överta. Oincheckade ändringar följer inte med i provet nedan. Kontrollera därför arbetsstatusen först och bestäm om ändringarna ska ingå i en senare commit. Skapa sedan en ny katalog bredvid originalprojektet. Använd inte en befintlig katalog med eget arbete. Kommandot clone tar här en lokal projektsökväg som källa; ingen publicering ingår.

Gör scriptgranskningen i steg 4 innan du kör npm ci nedan. Om du först behöver undersöka installationen utan installationsskript, använd npm ci --ignore-scripts i provkopian. Kör sedan om med projektets avsedda scriptinställningar efter granskningen; det begränsade försöket räcker inte som godkänt installationsprov.

git clone --no-local C:/projekt/ai-app C:/projekt/ai-app-installationsprov
if ($LASTEXITCODE -ne 0) { throw 'Kloningen misslyckades' }
Set-Location C:/projekt/ai-app-installationsprov
git checkout --detach KOMMIT_SHA
if ($LASTEXITCODE -ne 0) { throw 'Fel commit' }
git status --short
npm ci
if ($LASTEXITCODE -ne 0) { throw 'Installationen misslyckades' }

Byt KOMMIT_SHA mot värdet från inventeringen. Kontrollera att package.json, package-lock.json och eventuell .npmrc finns i kopian. Kör inventeringens versionskommandon igen här. Facit för detta steg är rätt commit, tom arbetsstatus före installationen och exitkod noll från installationen. Om projektet hämtar privata paket behöver provmiljön avsedd åtkomst; ett autentiseringsfel visar inte att lockfilen är fel.

Enligt npm ci-dokumentationen för CLI 11 krävs en befintlig lockfil. Kommandot installerar projektet, tar bort befintlig node_modules och skriver inte om manifest eller lockfiler genom sin egen installationsfunktion. Om lockfilen skapades med inställningar som påverkar trädet, exempelvis legacy-peer-deps eller install-links, behöver installationsprovet motsvarande inställningar. Lägg inte till en flagga på måfå efter ett fel; dokumentera varför projektet behöver den.

3. Prova manifestkonflikten utan att ändra originalet

Gör det negativa provet i ytterligare en arbetskopia av samma commit, exempelvis ai-app-konflikt. Behåll den lyckade kopian för byggprovet. Välj ett direkt registerberoende som redan finns i package.json och ange en annan, existerande exakt version som inte överensstämmer med lockfilens upplösning. Byt både PAKETNAMN och ANNAN_VERSION i kommandot nedan. För ett scoped paket eller ett projekt med lokala beroenden kan du redigera samma JSON-fält för hand i provkopian.

npm pkg set "dependencies.PAKETNAMN=ANNAN_VERSION"
git diff -- package.json package-lock.json
npm ci --ignore-scripts
$konfliktkod = $LASTEXITCODE
if ($konfliktkod -eq 0) { throw 'Konfliktprovet stoppade inte' }
git diff -- package-lock.json

Facit är att endast manifestet har ändrats före försöket, att npm stoppar för bristande överensstämmelse mellan manifest och lockfil och att lockfilen förblir oförändrad. Dokumentationen säger att denna konflikt ger fel i stället för en uppdaterad lockfil. Läs felorsaken: nätverksfel eller en version som inte finns är inte ett godkänt konfliktprov. Spara exitkod och den relevanta feltexten. Kör inte npm install som en automatisk rättning här, eftersom provet ska undersöka det incheckade kontraktet.

Om appen saknar direkta registerberoenden, dokumentera att just detta exempel inte passar och gör ett separat minimalt övningsprojekt med ett känt beroende. Förväxla inte övningens resultat med appens installation. Originalprojektet och den lyckade arbetskopian ska fortfarande innehålla sina ursprungliga manifest.

4. Hantera installationsskript och plattformsskillnader

Läs projektets scripts och granska vilka beroenden som behöver kod vid installationen innan du kör ett övertaget projekt med åtkomst till känsliga miljöer. npm:s lifecycle-dokumentation visar att installationen kan utlösa bland annat preinstall, install och postinstall. Ett projekt kan också ha prepare-steg. Det gör installationsbeslutet till mer än ett val av paketversioner.

Flaggan ignore-scripts stänger av package.json-scripts vid installationen. Den kan användas för en första avgränsad genomgång, men ett godkänt sådant försök visar inte att appens avsedda installation fungerar. Explicit begärda scripts kan fortfarande köras med npm run eller npm test; flaggan är därför ingen isolering av all kod. Beskriv i protokollet vilka scripts som tilläts. Kör efter granskning om installationen i den rena provmiljön med projektets avsedda scriptinställningar.

Anteckna om utvecklingsberoenden ingår. Med NODE_ENV satt till production utelämnas de normalt på disk; ett byggverktyg kan då saknas även när installationen lyckas. Använd projektets dokumenterade byggprofil och spara den. Undvik att jämföra en sådan installation direkt med en utvecklingsinstallation som om de mätte samma sak.

Kontrollera dessutom native-komponenter och plattformsbundna paket. package.json-dokumentationen beskriver begränsningar för operativsystem och CPU. Om produktionen kör Linux och ditt prov kör Windows behöver du ett motsvarande prov på målplattformen innan du hävdar att produktionsinstallationen fungerar. En lyckad installation på din dator är ett resultat för den miljön.

5. Kör bygg och test och kontrollera lockfilens diff

Gå tillbaka till den lyckade, oförändrade arbetskopian. Läs vad bygg- och testkommandona gör och kör de scripts du identifierade i steg ett. Följande exempel gäller ett projekt som faktiskt har build och test. Om de heter annorlunda, skriv deras namn i protokollet. Om ett test saknas, ange det uttryckligen; kalla inte en app med saknat testscript för testad.

npm run build
if ($LASTEXITCODE -ne 0) { throw 'Bygget misslyckades' }
npm test
if ($LASTEXITCODE -ne 0) { throw 'Testet misslyckades' }
git diff --exit-code -- package.json package-lock.json
if ($LASTEXITCODE -ne 0) { throw 'Beroendekontraktet ändrades' }
git status --short

Kontrollera arbetsstatusen även efter en tom diff. Den kan visa andra genererade eller ändrade filer som du behöver förklara. Scripts är projektkod och kan skriva filer; därför kontrollerar du kontraktet även efter bygg och test. Spara ett protokoll med commit, Node/npm, plattform, konfiguration, installationskod, konfliktens felorsak, körda scripts och slutlig diff. Ange också externa tjänster eller testfall som inte ingick.

Godkänt resultat betyder att den dokumenterade arbetskopian installerades och klarade de angivna proven utan ändrat beroendekontrakt. Det lovar inte att alla framtida miljöer ger samma binärer eller att appens alla funktioner fungerar. Använd CI-stoppreglerna för AI-genererad kod när du vill göra det här provet till en återkommande kontroll före merge.