Je jure que je passe 2 à 4 heures par semaine à faire fonctionner mon instance de développement.
Je fais un pnpm dedupe.
pfaffman@noreno:~/src/discourse-repos/discourse$ bin/ember-cli
Scope: all 17 workspace projects
Lockfile is up to date, resolution step is skipped
Already up to date
Done in 1.3s
Some V1 ember addons are resolving as incorrect peer dependencies. This makes it impossible for us to safely convert them to v2 format.
👇 👇 👇
👉 See https://github.com/embroider-build/embroider/blob/main/docs/peer-dependency-resolution-issues.md for an explanation of the problem and suggestions for fixing it.
👆 👆 👆
discourse@0.0.0 (dev)-> discourse-plugins@1.0.0 -> ember-this-fallback@0.4.0
sees peerDep ember-source@5.12.0
at /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
but discourse@0.0.0 is using ember-source@5.12.0
at /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
Et ensuite j’ai supprimé mes plugins et j’ai réessayé et j’obtiens cette erreur :
pnpm install -r
Scope: all 17 workspace projects
ERR_PNPM_PATCH_NOT_APPLIED The following patches were not applied: content-tag@3.1.0
Either remove them from "patchedDependencies" or update them to match packages in your dependencies.
Progress: resolved 1786, reused 1734, downloaded 0, added 0
J’ai fini par supprimer cette ligne pour que ember fonctionne :
Voici ce que je fais lorsque je récupère une nouvelle version de discourse :
cd "$DISCOURSE_SRC"
# NOTE: if bundler is broken, try `gem install bundler -v 2.5.3`
# Fine. We'll be in charge of at least creating a database
if psql -d discourse_development -c '\q' 2>/dev/null; then
# connection successful
echo "WE have postgres."
else
echo "No have discourse database"
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 "MISSING THE PLUGINS"
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 "\nUpdating the plugins\n "
./reset-all-repos
fi
if ! [[ -d $ALL_THE_THEMES ]]; then
echo "MISSING THE THEMES!!!"
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 "\nUpdating 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
# end of version updates
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-----------> Running pnpm update. . .\n"
pnpm update
echo -e "\n-----------> Running pnpm dedupe. . .\n"
pnpm dedupe
echo -e "\n-----------> Migrating the databases. . .\n"
LOAD_PLUGINS=1 ./bin/rails db:migrate
LOAD_PLUGINS=1 RAILS_ENV=test ./bin/rails db:migrate
exit
Pourquoi ? Cela modifie le fichier de verrouillage, ce que vous ne voulez vraiment pas faire (sauf si vous essayez délibérément de modifier les dépendances de Discourse). Si vous ne voulez pas modifier les dépendances, la seule commande pnpm dont vous aurez jamais besoin est pnpm install.
Les problèmes que vous avez décrits pourraient être causés si votre fichier de verrouillage pnpm a divergé de celui de core. Je vous recommande de vérifier toute différence (par exemple, via git status, ou tout autre outil graphique git que vous utilisez). S’il y a une différence, réinitialisez-la (par exemple, via git restore pnpm-lock.yaml)
Possiblement lié : Je vous recommande de supprimer --fix-lockfile de votre script d’installation. Le fichier de verrouillage de core n’a jamais besoin d’être “corrigé”, donc l’exécuter localement ne fera que provoquer une divergence.
Au fait, avez-vous essayé d’utiliser la configuration devcontainer. Elle vise à supprimer presque entièrement ce type de maintenance.
Bien qu’il soit vrai que si ce problème est effectivement que vous avez modifié votre fichier de verrouillage pnpm, alors il pourrait également se produire dans le devcontainer
Utilisez le lockfile de core. Si vous le supprimez et en régénérez un à partir de package.json, vous obtiendrez la dernière version absolue de chaque dépendance, ce qui causera certainement des problèmes.
Aussi, au fait, pnpm est très bon pour maintenir node_modules en ordre, donc vous ne devriez pas avoir besoin de le supprimer chaque fois que vous tirez core. Tout ce que je fais lorsque je tire core est bundle install && pnpm install && bin/rake db:migrate.
Quelque chose d’autre que j’ai essayé d’ajouter aujourd’hui ; je vais supprimer celui-ci.
Je ne l’ai pas fait exprès… Il est difficile de rendre les choses infaillibles quand les imbéciles sont si ingénieux.
Peut-être qu’un git clean -f était ce dont j’avais besoin. :personne_haussant_les_épaules:
Pas depuis des années. Je pense que je pensais que c’était plus lent ; peut-être est-ce moins vrai maintenant ? Devrais-je réessayer ? L’utilisez-vous ?
Ceci est un guide assez nouveau - ce n’est pas la même chose que l’ancien guide “docker dev”. (en fait… cela me rappelle… nous devrions probablement déprécier/supprimer cet ancien guide)
Sur macOS, la surcharge de virtualisation le rend un peu plus lent, surtout pour les tâches gourmandes en CPU comme l’exécution de la suite RSpec en parallèle. Mais pour le développement général, c’est très bien.
Je ne l’utilise pas 100% du temps, mais je l’utilise pour de petites tâches autonomes lorsque je ne veux pas toucher à mon environnement de développement principal. Par exemple : lorsque je vérifie la PR de quelqu’un d’autre lors d’une revue. Ou si j’ai besoin de faire des tests/développements sur la branche stable.
Ça a l’air bien ! Faites-nous savoir si cela résout le problème
Oh ! Peut-être que je dois lire le manuel. Peut-être que quelque chose a changé au cours des 5 dernières années. Peut-être que la prochaine fois que je serai frustré, je vérifierai cela. Merci.
Le git clean -f semble avoir résolu le problème. J’ai une fork de Discourse quelque part d’autre que je pourrais ostensiblement modifier pour faire une pull request, mais cette copie provient de la source originale, donc jeter les modifications n’est pas un problème (et probablement que toutes les modifications étaient des accidents de toute façon).
J’utilise principalement mon environnement de développement pour le développement de plugins.
Ça fonctionne à nouveau, et j’espère prudemment que mon script fonctionnera au moins pour les prochaines fois !
Aujourd’hui, je n’ai pas pu lancer mon environnement de développement car Discourse insistait sur pnpm 9.15.5 et npm insistait sur l’installation de la version 10.x. ‘pnpm --version’ m’indiquait 10.x dans mon répertoire personnel, mais refusait de s’exécuter dans le répertoire discourse. Cela m’a pris tout l’après-midi. J’ai finalement désinstallé pnpm avec npm et ajouté ceci à mon script de mise à jour :
J’ai essayé d’utiliser la magie de développement de docker, mais je n’arrive pas à comprendre comment lui passer des variables d’environnement, et il n’a même pas DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE défini, donc je ne pouvais pas me connecter.
Et maintenant, je reçois à nouveau ceci :
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
Je pense que je l’avais corrigé auparavant en modifiant . . . quelque chose.
OK. Voici comment corriger le problème de nice. Je ne comprends vraiment pas comment je suis le seul à être touché par cela.
Tant que vous avez ce commit de core, alors en théorie pnpm 10.x devrait automatiquement revenir à pnpm 9 lorsqu’il est exécuté dans core. Vous n’aurez besoin d’aucune technique d’installation personnalisée.
Immédiatement après la sortie de pnpm 10, certains membres de l’équipe ont eu des problèmes et ont pu les résoudre en exécutant pnpm self-update 9. Mais depuis que nous avons ajouté cette nouvelle configuration à core, je ne pense que quiconque ait eu besoin de faire quoi que ce soit manuellement.
Vous utilisez VSCode ? Si vous utilisez les tâches prédéfinies, vous pouvez ajouter des variables d’environnement dans tasks.json. Si vous lancez Rails/Ember via le terminal VSCode, vous pouvez ajouter les variables d’environnement en préfixe comme n’importe quel autre terminal.
C’est la première fois que je vois ça . Heureux que vous ayez réussi à le résoudre cependant !
Je suis curieux, quel système d’exploitation Linux utilisez-vous ?
Je suis sur d2a34bed8439557bfc37b8c08f89271be6903015 (qui devrait être après cela. Il a essayé d’exécuter pnpm 9, mais il ne l’a trouvé nulle part, donc il a refusé de s’exécuter car il voulait vraiment, vraiment, vraiment sa propre version. Et rien de ce que j’ai pu faire ne l’a installé jusqu’à ce que je prenne les choses en main avec asdf.
J’utilise POP!OS, que je pensais être principalement Ubuntu standard sous le capot, mais peut-être qu’ils modifient les valeurs de renice et que je suis le seul à qui cela est arrivé. Je ne me souviens pas quand cela a commencé, mais cette fois, je l’ai finalement corrigé au niveau du système d’exploitation et non en modifiant le cœur !
