Ember-Addons werden als falsche Peer-Abhängigkeiten aufgelöst. -- behoben durch Entfernen von "content-tag@3.1.0": "patches/content-tag@3.1.0.patch"

Ich schwöre, ich verbringe 2-4 Stunden pro Woche damit, meine Entwicklungsinstanz am Laufen zu halten.

Ich führe einen pnpm dedupe aus.

pfaffman@noreno:~/src/discourse-repos/discourse$ bin/ember-cli
Scope: alle 17 Workspace-Projekte
Lockfile ist auf dem neuesten Stand, Auflösungsschritt wird übersprungen
Bereits auf dem neuesten Stand
Fertig in 1,3s
Einige V1 Ember-Addons werden als falsche Peer-Abhängigkeiten aufgelöst. Dies macht es uns unmöglich, sie sicher in das v2-Format zu konvertieren.

👇 👇 👇
👉 Siehe https://github.com/embroider-build/embroider/blob/main/docs/peer-dependency-resolution-issues.md für eine Erklärung des Problems und Vorschläge zur Behebung.
👆 👆 👆

discourse@0.0.0 (dev) -> discourse-plugins@1.0.0 -> ember-this-fallback@0.4.0
  sieht peerDep ember-source@5.12.0
    bei /home/pfaffman/src/discourse-repos/discourse/node_modules/.pnpm/ember-source@5.12.0_patch_hash=xx7mvsb7nmshqkkqhmf45r3hse_@glimmer+component@1.1.2_@babel+cor_fw7srrjre4qclkyiv6wvjvr6va/node_modules/ember-source
    aber discourse@0.0.0 verwendet ember-source@5.12.0
      bei /home/pfaffman/src/discourse-repos/discourse/node_modules/.pnpm/ember-source@5.12.0_patch_hash=xx7mvsb7nmshqkkqhmf45r3hse_@glimmer+component@1.1.2_@babel+cor_stof4qukza26ryuxyhy7me4cya/node_modules/ember-source

Und dann habe ich meine Plugins entfernt und es erneut versucht und erhalte diese Fehlermeldung:


pnpm install -r
Scope: alle 17 Workspace-Projekte
ERR_PNPM_PATCH_NOT_APPLIED Die folgenden Patches wurden nicht angewendet: content-tag@3.1.0

Entfernen Sie sie entweder aus \"patchedDependencies\" oder aktualisieren Sie sie, damit sie mit den Paketen in Ihren Abhängigkeiten übereinstimmen.
Fortschritt: aufgelöst 1786, wiederverwendet 1734, heruntergeladen 0, hinzugefügt 0

Ich habe schließlich diese Zeile entfernt, damit Ember funktioniert:

Hier ist, was ich tue, wenn ich eine neue Discourse-Version herunterlade:

  cd "$DISCOURSE_SRC"
  # HINWEIS: Wenn Bundler defekt ist, versuchen Sie `gem install bundler -v 2.5.3`

  # Gut. Wir werden dafür verantwortlich sein, zumindest eine Datenbank zu erstellen
  if psql -d discourse_development -c '\q' 2>/dev/null; then
    # Verbindung erfolgreich
    echo "Wir haben Postgres."
  else
    echo "Keine Discourse-Datenbank vorhanden"
    cd /tmp && sudo su -c "su postgres -c 'createuser -s \"$USER\"'"
    cd $DISCOURSE_SRC
    LOAD_PLUGINS=1 ./bin/rails db:create
    LOAD_PLUGINS=1 RAILS_ENV=test ./bin/rails db:create
    echo "CREATE EXTENSION IF NOT EXISTS vector;" | psql
  fi

  if ! [[ -d $ALL_THE_PLUGINS ]]; then
    echo "DIE PLUGINS FEHLEN"
    cd $SRC
    git clone https://github.com/discourse/all-the-plugins
    cd $ALL_THE_PLUGINS
    ./reset-all-repos
  fi
  cd $ALL_THE_PLUGINS
  if [ -z "$(find official -mmin -100)" ]; then
    echo -e "\nAktualisiere die Plugins\n "
    ./reset-all-repos
  fi

  if ! [[ -d $ALL_THE_THEMES ]]; then
    echo "DIE THEMES FEHLEN!!!"
    sleep 5
    cd $SRC
    git clone https://github.com/discourse/all-the-themes
    cd $ALL_THE_THEMES
    ./reset-all-repos
  fi

  cd $ALL_THE_THEMES
  if [ -z "$(find official -mmin -100)" ]; then
    echo -e "\nAktualisiere Themes. . .\n"
    ./reset-all-repos
  fi

  asdf plugin add ruby 2>&1 |grep -v "already"
  asdf plugin add imagemagick 2>&1 |grep -v "already"
  asdf plugin update --all > /dev/null

  docker pull discourse/base:release
  RUBY_VERSION=$(docker run discourse/base:release bash -c 'ruby --version'|cut -d' ' -f2)
  LOCAL_RUBY_VERSION=$(ruby --version|cut -d' ' -f2)
  echo "Got RUBY_VERSION $RUBY_VERSION"
  asdf install ruby $RUBY_VERSION 2>&1 |grep -v "already"
  asdf global ruby $RUBY_VERSION 2>&1 |grep -v "already"
  IMAGE_MAGICK_VERSION=$(docker run discourse/base:release bash -c 'convert --version'|head -1|cut -d' ' -f3)
  echo "Got IMAGE_MAGICK_VERSION: $IMAGE_MAGICK_VERSION"
  asdf install imagemagick $IMAGE_MAGICK_VERSION 2>&1 |grep -v "already"
  asdf global imagemagick $IMAGE_MAGICK_VERSION 2>&1 |grep -v "already"

  # 2025-01-13 get node version from the base container!
  NODE_VERSION=$(docker run discourse/base:release bash -c 'node --version'|cut -d'v' -f2)
  echo "GOT NODEJS version: $NODE_VERSION"
  asdf install nodejs $NODE_VERSION 2>&1|grep -v "already"
  asdf global nodejs $NODE_VERSION 2>&1|grep -v "already"

  npm install -g pnpm

  # Ende der Versionsaktualisierungen
  cd $DISCOURSE_SRC
  git checkout main
  git pull
  bundle install
  rm -rf node_modules pnpm-lock.yaml
  pnpm install -r --fix-lockfile

  echo -e "\n-----------> Führe pnpm update aus. . .\n"
  pnpm update
  echo -e "\n-----------> Führe pnpm dedupe aus. . .\n"
  pnpm dedupe
  echo -e "\n-----------> Migriere die Datenbanken. . .\n"
  LOAD_PLUGINS=1 ./bin/rails db:migrate
  LOAD_PLUGINS=1 RAILS_ENV=test ./bin/rails db:migrate
  exit
2 „Gefällt mir“

Warum? Das ändert die Lockfile, was man wirklich nicht tun möchte (es sei denn, man versucht absichtlich, die Abhängigkeiten von Discourse zu ändern). Wenn man die Abhängigkeiten nicht ändern möchte, ist der einzige pnpm-Befehl, den man jemals brauchen sollte, pnpm install.

Die von Ihnen beschriebenen Probleme könnten dadurch verursacht werden, dass Ihre pnpm-Lockfile von der Core-Lockfile abgewichen ist. Ich empfehle, nach Unterschieden zu suchen (z. B. über git status oder eine beliebige Git-GUI, die Sie verwenden). Wenn es einen Unterschied gibt, setzen Sie ihn zurück (z. B. über git restore pnpm-lock.yaml).

Möglicherweise verwandt: Ich empfehle, --fix-lockfile aus Ihrem Installationsskript zu entfernen. Die Lockfile von Core muss niemals „repariert“ werden, daher ist die lokale Ausführung dieses Befehls wahrscheinlich nur dazu da, eine Abweichung zu verursachen.

Haben Sie übrigens versucht, das Devcontainer-Setup zu verwenden? Es zielt darauf ab, diese Art von Wartung fast vollständig zu eliminieren.

Obwohl zugegeben, wenn dieses Problem tatsächlich darin besteht, dass Sie Ihre pnpm-Lockfile geändert haben, könnte es auch im Devcontainer auftreten :sweat_smile:

1 „Gefällt mir“

Oh, ja… das wird es tun :eyes:

Verwenden Sie die Lock-Datei von Core. Wenn Sie sie löschen und eine neue aus package.json generieren, erhalten Sie die absolut neueste Version jeder Abhängigkeit, was definitiv zu Problemen führen wird.

Außerdem ist pnpm sehr gut darin, node_modules in Ordnung zu halten, sodass Sie es nicht jedes Mal löschen müssen, wenn Sie Core ziehen. Alles, was ich beim Ziehen von Core mache, ist bundle install && pnpm install && bin/rake db:migrate.

Weil das das letzte Problem behoben hat, das ich hatte?

Etwas anderes, das ich heute versucht habe hinzuzufügen; ich werde das entfernen.

Ich habe es nicht absichtlich geändert… Es ist schwer, Dinge narrensicher zu machen, wenn Narren so einfallsreich sind.

Vielleicht brauchte ich ein git clean -f. :person_shrugging:

Seit Jahren nicht mehr. Ich glaube, ich dachte, es wäre langsamer; vielleicht stimmt das jetzt weniger? Vielleicht sollte ich es nochmal versuchen? Benutzen Sie es?

Dies ist eine ziemlich neue Anleitung – sie ist nicht dasselbe wie die alte „docker dev“-Anleitung. (Tatsächlich… das erinnert mich… wir sollten diese alte Anleitung wahrscheinlich als veraltet kennzeichnen/entfernen)

Unter macOS macht der Virtualisierungs-Overhead es etwas langsamer, insbesondere bei CPU-intensiven Aufgaben wie dem parallelen Ausführen der RSpec-Suite. Aber für die allgemeine Entwicklung ist es sehr gut.

Ich benutze es nicht 100% der Zeit, aber ich benutze es für kleine, in sich geschlossene Aufgaben, wenn ich meine Hauptentwicklungsumgebung nicht anfassen möchte. Zum Beispiel: wenn ich den Pull-Request eines anderen während der Überprüfung auschecke. Oder wenn ich einige Tests/Entwicklungen am stable-Branch durchführen muss.

Klingt gut! Lassen Sie uns wissen, ob das die Dinge zum Laufen bringt :crossed_fingers:

Oh! Vielleicht muss ich das Handbuch lesen. Vielleicht hat sich in den letzten 5 Jahren etwas geändert. Vielleicht werde ich das beim nächsten Mal, wenn ich frustriert bin, überprüfen. Danke.

Das git clean -f scheint es behoben zu haben. Ich habe irgendwo anders eine Fork von Discourse, die ich angeblich bearbeiten könnte, um einen PR zu erstellen, aber diese Kopie stammt aus der Originalquelle, daher ist es kein Problem, Änderungen zu verwerfen (und wahrscheinlich waren alle Änderungen sowieso versehentlich).

Ich benutze meine Entwicklungsumgebung hauptsächlich für die Plugin-Entwicklung.

Es funktioniert jetzt wieder, und ich bin vorsichtig optimistisch, dass mein Skript für die nächsten Male funktionieren wird!

2 „Gefällt mir“

Heute konnte ich meine Entwicklungsumgebung nicht ausführen, da Discourse auf pnpm 9.15.5 bestand und npm darauf bestand, 10 etwas zu installieren. ‘pnpm --version’ würde mir 10.x in meinem Home-Verzeichnis anzeigen, aber im Discourse-Verzeichnis würde es sich weigern zu laufen. Es hat den ganzen Nachmittag gedauert. Ich habe pnpm schließlich mit npm deinstalliert und stattdessen dies zu meinem Update-Skript hinzugefügt:

  PNPM_VERSION=$(docker run discourse/base:release bash -c 'pnpm --version'|cut -d'v' -f2)
  echo "GOT PNPM version: $PNPM_VERSION"
  asdf install pnpm $PNPM_VERSION 2>&1|grep -v "already"
  asdf global pnpm $PNPM_VERSION 2>&1|grep -v "already"

Das scheint zu funktionieren.

Ich habe versucht, die Docker-Entwicklungs-Magie zu nutzen, aber ich kann nicht herausfinden, wie ich ENV daran übergeben kann, und es hat nicht einmal DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE gesetzt, sodass ich mich nicht anmelden konnte.

Und jetzt bekomme ich das wieder:

 Error encountered while starting Sidekiq: [Discourse::Utils::CommandError] /home/pfaffman/src/discourse-repos/discourse/lib/discourse.rb:139:in `exec': renice: failed to set priority for 116553 (process ID): Permission denied

Ich glaube, ich habe es vorher behoben, indem ich . . . etwas bearbeitet habe.

OK. Hier ist, wie man das Nice-Problem behebt. Ich schwöre, ich sehe nicht, wie ich der Einzige bin, der davon betroffen ist.

In einer Datei wie

sudo nano /etc/security/limits.d/90-pfaffman-nice.conf

Fügen Sie etwas hinzu wie

pfaffman soft priority 5
pfaffman hard priority 5
1 „Gefällt mir“

Solange Sie diesen Commit in Core haben, sollte pnpm 10.x in der Theorie automatisch auf pnpm 9 zurückfallen, wenn es in Core ausgeführt wird. Sie benötigen keine benutzerdefinierte Installationstechnik.

Unmittelbar nach der Veröffentlichung von pnpm 10 hatten einige Teammitglieder Probleme und konnten diese durch Ausführen von pnpm self-update 9 lösen. Aber seit wir diese neue Konfiguration zu Core hinzugefügt haben, glaube ich nicht, dass jemand manuell etwas tun musste.

Verwenden Sie VSCode? Wenn Sie die vordefinierten Aufgaben verwenden, können Sie die Umgebungsvariablen in tasks.json hinzufügen. Wenn Sie Rails/Ember über das VSCode-Terminal starten, können Sie die Umgebungsvariablen wie in jedem anderen Terminal als Präfix hinzufügen.

Das ist neu für mich :sweat_smile:. Aber ich bin froh, dass Sie es lösen konnten!

Ich bin neugierig, welches Linux-Betriebssystem Sie verwenden?

Ich bin auf d2a34bed8439557bfc37b8c08f89271be6903015 (was danach sein sollte. Es versuchte, pnpm 9 auszuführen, aber es war nirgends zu finden, also weigerte es sich zu laufen, weil es seine eigene Version unbedingt wollte. Und nichts, was ich tun konnte, würde es installieren, bis ich die Angelegenheiten in die Hände von asdf legte.

Golly. Heck. Nein. Ich habe nach “development docker” gesucht und anscheinend den alten Weg gefunden: Install Discourse for development using Docker. Könnte jemand vielleicht darauf verlinken Developing Discourse using a Dev Container, wenn das jetzt das ist, was wir mögen?

Ich benutze POP!OS, von dem ich dachte, dass es größtenteils Standard-Ubuntu unter der Haube ist, aber vielleicht ändern sie die renice-Werte und ich bin der Einzige, dem das passiert ist. Ich kann mich nicht erinnern, wann es angefangen hat, aber diesmal habe ich es endlich auf Betriebssystemebene behoben und nicht durch die Bearbeitung von Core!

2 „Gefällt mir“