Soll ich die `.pnp.js`-Datei von Garn übertragen?

Lesezeit: 2 Minuten

Benutzer-Avatar
darylp

Garn enthält eine optionale “Plug’n’Play”-Funktion was sich bewegt node_modules aus dem Projektverzeichnis. Dabei entsteht ein .pnp.js Datei mit Verweisen auf verschiedene Abhängigkeitspfade auf der Festplatte.

Die Datei wird automatisch generiert, ist mehrere tausend Zeilen lang und scheint auf Pfade zu verweisen speziell für die Maschine das lief yarn install.

Ist .pnp.js soll mit dem Rest des Codes begangen werden? Ich kann anscheinend keine Informationen darüber finden, obwohl die Datei scheinbar nutzlos zu übergeben ist. Was gilt als Best Practice und warum?

ich fand dieser Kommentar von Arcanis (der Hauptbetreuer von Yarn) zu einem Problem, bei dem es darum ging, was in a aufgenommen werden soll .gitignore. Vielleicht beantwortet es deine Frage:

  • .yarn/plugins und .yarn/releases enthalten die Yarn-Releases, die im aktuellen Repository verwendet werden (wie definiert von yarn set version). Sie sollten sie versioniert halten (dies verhindert potenzielle Probleme, wenn beispielsweise zwei Ingenieure unterschiedliche Yarn-Versionen mit unterschiedlichen Funktionen verwenden).

  • .yarn/unplugged sollte wahrscheinlich immer ignoriert werden, da es native Builds enthalten kann

  • .yarn/build-state.yml sollte wahrscheinlich ebenfalls ignoriert werden, da es die Build-Infos enthält

    • Wenn Sie aus irgendeinem Grund Version unpluggedkann es sinnvoll sein, sie beizubehalten build-state auch
  • .yarn/cache kann ignoriert werden, aber Sie müssen laufen yarn install um es zu regenerieren

    • Die Versionierung schaltet das frei, was wir nennen Zero-Installationen – Es ist jedoch optional
  • .pnp.js (und evtl .pnp.data.json) sitzen im selben Boot wie der Cache. Fügen Sie es Ihrem Repository hinzu, wenn Sie Ihren Cache in Ihrem Repository behalten, und ignorieren Sie es andernfalls.

  • yarn.lock sollte immer in Ihrem Repository gespeichert werden (selbst wenn Sie eine Bibliothek entwickeln)

Also zusammenfassend:

Wenn Sie Zero-Installs verwenden:

.yarn/unplugged
.yarn/build-state.yml

Wenn Sie Zero-Installs nicht verwenden:

.yarn/*
!.yarn/releases
!.yarn/plugins
.pnp.*

  • Was ist eine Nullinstallation

    – Benutzer1354934

    25. April 2020 um 23:57 Uhr

  • Zero Install ist eine Funktion von Garn 2/Beere, mit der Sie klonen und ausführen können

    – Thom

    27. April 2020 um 20:38 Uhr

  • Hier sind die offizielle .gitignore-Empfehlungen

    – Daniel

    9. Dezember 2020 um 14:08 Uhr

Benutzer-Avatar
Nikolaus Petersen

Wie einer der Kommentatoren feststellte, die offiziellen .gitignore-Empfehlungen sind hier, zusammen mit hervorragenden Kommentaren. Die einzige Kritik, die ich habe, ist die Art und Weise, wie sie es dort gezeigt haben. Ich denke, sie hätten die üblichen Methoden zu einer kombinieren und dann die Sonderfälle für Null-Installation und Nicht-Installation trennen sollen. Hier ist, wie ich es habe. Beachten Sie aber noch einmal diesen Artikel, da einige davon (z .yarn/sdk) optional hinzugefügt werden oder nicht.

# ------- yarn -------
# see excellent notes at: https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
# Also: `yarn.lock` and `.yarnrc.yml` (or it's older counterpart .yarnrc) "should always be stored in your repo"
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

## --> ADD if using zero-install, otherwise do NOT:
#!.yarn/cache

## --> ELSE ADD if NOT using yarn's zero-install:
.pnp.*

# ------- end yarn -------

1180670cookie-checkSoll ich die `.pnp.js`-Datei von Garn übertragen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy