Ich arbeite an einem ziemlich großen React-Projekt und jedes Mal, wenn ich ein neues Package installiere, lande ich bei absurden Versionskonflikten. Ich habe versucht, npm ci zu nutzen, aber das funktioniert nicht immer, besonders wenn ich mit anderen zusammenarbeite. Gibt es einen intelligenteren Weg, um diese Situation zu handhaben, ohne alles von vorne anzufangen?
Fass die `package-lock.json` niemals von Hand an, das ist der erste Fehler! Was mir mega geholfen hat, ist `npm ci` lokal zu nutzen und vor allem eine `.npmrc` mit `save-exact=true` im Projekt zu konfigurieren. So werden bei neuen Installationen die exakten Versionen gespeichert, statt mit `^` und `~`, die nur Chaos verursachen.
Dann packst du noch einen Pre-Commit-Hook mit Husky rein, der jeden blockiert, der versucht, eine kaputte `package-lock.json` zu committen - banal, aber funktioniert wahnsinnig gut, weil das Team nicht versehentlich alles zerstören kann. Und wenn du wirklich ein Package hinzufügen musst, mach es immer mit `npm install --save-exact paketname` und lass es von jemandem checken, bevor du pushst!
Wenn du diese Konflikte hast, passiert das normalerweise, wenn du neue Packages mit `npm install` installierst, ohne zu überprüfen, was das mit der `package-lock.json` macht, richtig?
Das Problem ist, dass npm standardmäßig etwas zu flexibel ist. Zunächst mal stell sicher, dass alle im Team `npm ci` statt `npm install` verwenden, wenn sie an einem bereits laufenden Projekt arbeiten. Der Unterschied ist, dass `npm ci` genau das liest, was in der `package-lock.json` steht, ohne sie zu verändern, während `install` anfängt, Patch- und Minor-Versionen hochzufahren, wenn es ihm gerade passt. Wenn du `npm install` verwendest, um neue Sachen hinzuzufügen, und dann das Lock-File pusht, haben die anderen plötzlich unterschiedliche Versionen. Außerdem solltest du die `package-lock.json` immer ins Repository committen - klingt banal, aber viele machen das nicht und wundern sich dann, warum der Build fehlschlägt.
Für neue Packages benutze `npm install --save-exact`, wenn du wirklich eine bestimmte Version einfrieren willst, oder schau dir Tools wie `npm audit` an, um zu überprüfen, ob es bekannte Dependency-Konflikte gibt. Wenn das Problem sehr gravierend ist mit vielen verschachtelten Abhängigkeiten, kannst du auch `npm dedupe` ab und zu verwenden, um den Dependency-Baum aufzuräumen. Eigentlich könntest du auch pnpm oder Yarn ausprobieren, wenn du bereit bist, das Ökosystem zu wechseln - die verwalten Abhängigkeiten ordentlicher - aber wenn du bei npm bleiben willst, sollte das Einhalten des `ci` + `package-lock.json` im Git-Workflow die meisten Probleme lösen.
Das, was mich wirklich gerettet hat, ist immer `npm ci` zu benutzen, aber vor allem darauf zu bestehen, dass das ganze Team das macht - nicht `npm install`. Sobald jemand ein Standard-`install` macht, um ein Package hinzuzufügen, ändert sich die `package-lock.json` auf komische Weise und dann haben die anderen absurde Merge Conflicts.
Was ich mache, ist `npm install <package> --save` nur zu benutzen, wenn ich wirklich neue Sachen hinzufügen muss, und ich lasse das Lock File aktualisieren, dann committe ich alles zusammen.
Aber der echte Trick ist, die Versionen in der `package.json` mit konservativeren Ranges zu konfigurieren - sowas wie `^16.0.0` statt `*` - damit React sich nicht auf eine Minor Version aktualisiert, die alles zerstört. Ich habe große Projekte gesehen, wo sie einfach eine gemeinsame `.npmrc`-Datei ins Repo gepackt haben mit `save-exact=true`, damit jedes neue Package auf eine exakte Version gepinnt wird. Das ist starrer, aber wenigstens drehst du nicht durch, wenn du zusammenarbeitest.
Anmeldenzum Beantworten.
