Discourse Core wechselt zu pnpm für die JS-Paketverwaltung

Wir stellen den JS-Paketmanager von Discourse Core von ‘yarn classic’ auf pnpm um. Dies wird zu erheblichen Verbesserungen bei der Installationsgeschwindigkeit und den Speicheranforderungen führen.

Produktion

Wenn Sie Managed Hosting oder eine Standardinstallation verwenden, müssen Sie nichts weiter tun. Die Änderung wird bei Ihrem nächsten Update automatisch angewendet.

Wenn Sie eine benutzerdefinierte Produktionsumgebung haben, müssen Sie alle yarn ...-Befehle in pnpm ... ändern.

Entwicklung

Nachdem Sie die neueste Version von Discourse Core heruntergeladen haben, sehen Sie möglicherweise eine Fehlermeldung wie diese beim Starten des Servers:

pnpm ist nicht installiert

oder, wenn Sie einen Befehl wie yarn install ausführen, sehen Sie

Fehler discourse@: Die Engine "yarn" ist mit diesem Modul inkompatibel. Erwartete Version "please-use-pnpm". Erhalten "...".

Um dies zu beheben, sollten Sie:

  1. npm install -g pnpm ausführen
  2. pnpm install ausführen
  3. Alle Verwendungen von yarn ... in Ihrer Entwicklungsumgebung durch pnpm ... ersetzen

Plugins / Themes

Wir haben unsere offiziellen Plugins/Themes umgestellt, um pnpm für ihre Linting-Abhängigkeiten zu verwenden.

Für die discourse_theme CLI müssen Sie Ihre lokale Version aktualisieren, indem Sie gem update discourse_theme ausführen.

Zurück zu yarn wechseln

Wenn Sie zu einer yarn-basierten Version von Discourse zurückkehren müssen (z. B. wenn Sie an einem stabilen Branch entwickeln), müssen Sie alle node_modules-Verzeichnisse von Core manuell löschen:

rm -rf node_modules app/assets/javascripts/*/node_modules
24 „Gefällt mir“

Ich kann eine fehlerfreie, reibungslose Erfahrung auf der Entwicklerumgebung melden, die auf Anhieb funktioniert, vielen Dank! :rocket:

7 „Gefällt mir“

Wenn Sie selbst gehostet sind. Müssen wir etwas tun, wenn wir keine benutzerdefinierten Komponenten und Plugins verwenden?

Ich meine, einige Plugins und Komponenten sind nicht offiziell.

3 „Gefällt mir“

Wenn Sie unsere Standardinstallation verwenden, müssen Sie nichts weiter tun. Es sind keine Änderungen an Plugins oder Themes erforderlich.

5 „Gefällt mir“

Sollen wir diese erwartete Version vielleicht ändern in:

please-use-pnpm-see-https://meta.discourse.org/t/324521

:smiley:

6 „Gefällt mir“

Ich trage zu einem anderen FOSS-Projekt bei, wo ich kürzlich zum ersten Mal mit PNPM in Berührung kam. Der Übergang war ein Kinderspiel, reibungslos, effektiv und eine echte Freude.

Ich habe sehr kurze Notizen in der Dokumentation dieses Projekts darüber verfasst, was PNPM ist und wie man es benutzt. Obwohl die winzigen Details für jedes Projekt unterschiedlich sind, hoffe ich, dass das, was dort steht, eine schnelle Einführung für jeden hier bieten kann, der wie ich keine Ahnung hatte, bevor eine Ankündigung gemacht wurde.

5 „Gefällt mir“

Gute Ressource, danke @TonyG

Es ist jedoch erwähnenswert, dass keine der dortigen „Konfigurationshinweise“ für Discourse erforderlich sind. Ich bin mir nicht sicher, warum sie es brauchen… vielleicht weil es eine Windows-basierte Anwendung ist?

Auch ihre Anmerkung „In einem vorhandenen Projekt einfach den Ordner ‚node_modules‘ löschen“ wird in Discourse automatisch von diesem Skript gehandhabt :sunglasses:

Für uns sollte es also wirklich so einfach sein:

npm install -g pnpm
pnpm install
1 „Gefällt mir“

Eine Frage hier, David:

Wie führe ich Linting lokal aus?

d.h. was ersetzt z.B.: yarn prettier --write plugins/discourse-events

Ich habe versucht auszuführen

pnpm pprettier --write plugins/discourse-events

aber es gibt einen Fehler aus:

Error: File not found with singular glob: /Users/blah/dev/disc/discourse/plugins/discourse-events (if this was purposeful, use allowEmpty option)

Ich glaube, da hast du zu viele p drin?

Also willst du:

pnpm prettier --write plugins/discourse-events

pprettier ist ein Werkzeug, um Prettier parallel auszuführen, aber ich schätze, es unterstützt nicht das Ausführen in einem einzelnen Verzeichnis auf diese Weise.

3 „Gefällt mir“

Vielen Dank für Ihren Beitrag zu FOSS-Dokumenten, @david :lol_: Es sieht so aus, als ob die Seite auf Windows ausgerichtet ist und die dortigen Informationen für die Verwendung von pnpm erforderlich sein könnten. Ich werde bearbeiten und klarstellen, dass beides für dieses Dienstprogramm nicht der Fall ist.

Um es klarzustellen: Die Informationen darüber, wie pnpm funktioniert, dienen nur dem Komfort des Benutzers/Entwicklers, einschließlich derjenigen hier, die dieses neue Werkzeug, das ein bedeutendes, häufig verwendetes Werkzeug in unserem Werkzeugkasten ersetzt, verstehen möchten.

Für Discourse-Entwickler erklären diese Informationen, wo sich Dinge befinden und wie Standardorte geändert werden können. Dies soll eine Frage beantworten wie: „Wenn sich alle meine node_modules jetzt an einem Ort befinden, wo sind sie?“ Im Discourse-Container möchten Sie Entwickler möglicherweise keine Pakete am Standardort haben. Wenn ein Plugin-Entwickler aus irgendeinem Grund direkt auf den Ordner node_modules verweist und Links zu einem anderen Speicherort anstelle von Dateien findet, erklären die Informationen auf dieser Seite prägnant, wie dieser Speicherort bestimmt wird.

So viel dazu, dass ich versucht habe, kurz zu sein. :facepalm: :lolsob:

Auf jeden Fall eine gute Entscheidung für pnpm und danke.

2 „Gefällt mir“

Ja, pprettier war nicht angemessen, danke.

Ich habe auch mein ultimatives Problem gelöst.

Man muss offenbar pnpm install im Plugin-Verzeichnis ausführen, bevor man Linting-Prüfungen durchführen kann (selbst vom Discourse-Verzeichnis aus).

2 „Gefällt mir“

Hmm interessant :denkend:

Mit unserem Standard-Plugin-Skelett hat jedes Plugin seine eigene package.json-Datei mit seinen Linting-Abhängigkeiten. Und vorerst verwendet das Skelett immer noch yarn.

Um ein bestimmtes Plugin zu linten, würden Sie also in das Plugin-Verzeichnis wechseln und Folgendes ausführen:

yarn install
yarn prettier --write

Die Verwendung der Linting-Konfiguration des Kerns für Plugins kann manchmal funktionieren. Aber wenn die Version/Konfiguration abweicht, kann es schmerzhaft werden, da die Version von eslint/prettier im Kern nicht mit der Version übereinstimmt, die in der CI Ihres Plugins ausgeführt wird.

1 „Gefällt mir“

Würden wir in Erwägung ziehen, pnpm auch aus dem Plugin-Verzeichnis zu verwenden?

Ich glaube, es verwendet immer noch die lokale package.json, oder?

3 „Gefällt mir“

Ja, das werden wir auf jeden Fall tun! Wir lassen nur den Staub über die Kernänderung legen, bevor wir dieses Abenteuer beginnen.

(Fun Fact: CDCK pflegt fast 600 Theme-/Plugin-Repositorys, die alle aktualisiert werden müssen :sweat_smile:)

2 „Gefällt mir“

Klar, keine Probleme!

1 „Gefällt mir“

Dies scheint korrekt funktioniert zu haben, war aber verwirrt von dem Hinweis, der besagt, dass dies manuell erfolgen muss und nicht automatisch für Standardinstallationssites:

2 „Gefällt mir“

Danke @Architect. Diese PRs unterdrücken die Upgrade-Meldungen:

6 „Gefällt mir“

Beim Upgrade über das Web-Tool ist ein Problem aufgetreten — die Upgrade-Seite meldete, dass das Upgrade fehlgeschlagen sei, mit dem Fehler Expected version "please-use-pnpm", aber als ich die Versionsseite anschließend erneut besuchte, schien das Upgrade erfolgreich gewesen zu sein:

…jedoch funktionieren jetzt keine der Admin-Seiten mehr:

Update:
Ich habe einen Rebuild über die Kommandozeile durchgeführt und das hat die Dinge behoben.

3 „Gefällt mir“

Danke für die Meldung, @alxndr.

Ich habe gerade diesen Fix veröffentlicht, der verhindern sollte, dass dies anderen passiert.

4 „Gefällt mir“

Vielleicht liegt es an unserer Communiteq-Umgebung, aber ehrlich gesagt sehe ich keine signifikanten Geschwindigkeitsverbesserungen während der Installation? Unsere stabile Testinstallation installiert sogar 23 Sekunden schneller als die bestandene Testversion.

1 „Gefällt mir“