Giuro che passo 2-4 ore a settimana a mantenere funzionante la mia istanza di sviluppo.
Eseguo 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
E poi ho rimosso i miei plugin e ho riprovato, ottenendo questo errore:
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
Ho finito per rimuovere questa riga per far funzionare ember:
Ecco cosa faccio quando scarico una nuova versione di discourse:
cd "$DISCOURSE_SRC"
# NOTA: se bundler è rotto, prova `gem install bundler -v 2.5.3`
# Va bene. Saremo responsabili almeno della creazione di un database
if psql -d discourse_development -c '\q' 2>/dev/null; then
# connessione riuscita
echo "ABBIAMO postgres."
else
echo "Non abbiamo il database discourse"
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 "MANCANO I PLUGIN"
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 "\nAggiornamento dei plugin\n "
./reset-all-repos
fi
if ! [[ -d $ALL_THE_THEMES ]]; then
echo "MANCANO I TEMI!!!"
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 "\nAggiornamento dei temi. . .\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 "Ottenuto 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 "Ottenuto 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 "OTTENUTA versione NODEJS: $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
# fine degli aggiornamenti di versione
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-----------> Esecuzione pnpm update. . .\n"
pnpm update
echo -e "\n-----------> Esecuzione pnpm dedupe. . .\n"
pnpm dedupe
echo -e "\n-----------> Migrazione dei database. . .\n"
LOAD_PLUGINS=1 ./bin/rails db:migrate
LOAD_PLUGINS=1 RAILS_ENV=test ./bin/rails db:migrate
exit
Perché? Questo modifica il lockfile, cosa che non dovresti fare (a meno che tu non stia deliberatamente cercando di modificare le dipendenze di Discourse). Se non vuoi modificare le dipendenze, l’unico comando pnpm di cui dovresti aver bisogno è pnpm install.
I problemi che hai descritto potrebbero essere causati se il tuo pnpm lockfile è divergente da quello di core. Ti consiglio di verificare eventuali differenze (ad esempio tramite git status, o qualsiasi GUI git tu utilizzi). Se c’è una differenza, reimpostala (ad esempio tramite git restore pnpm-lock.yaml)
Possibilmente correlato: ti consiglio di rimuovere --fix-lockfile dal tuo script di installazione. Il lockfile di core non dovrebbe mai aver bisogno di essere “corretto”, quindi eseguirlo localmente potrebbe solo causare divergenza.
A proposito, hai provato a usare la configurazione devcontainer. Mira a rimuovere quasi completamente questo tipo di manutenzione.
Anche se, ammettiamolo, se questo problema è effettivamente che hai modificato il tuo pnpm lockfile, allora potrebbe verificarsi anche nel devcontainer
Usa il lockfile di core. Se lo elimini e ne rigeneri uno da package.json, otterrai la versione più recente in assoluto di ogni dipendenza, il che causerà sicuramente problemi.
Inoltre, tra parentesi, pnpm è molto bravo a mantenere node_modules in ordine, quindi non dovresti aver bisogno di eliminarlo ogni volta che esegui il pull di core. Tutto quello che faccio quando eseguo il pull di core è bundle install && pnpm install && bin/rake db:migrate.
Questa è una guida piuttosto nuova, non è la stessa cosa della vecchia guida “docker dev”. (infatti… questo mi ricorda… dovremmo probabilmente deprecate/rimuovere quella vecchia guida)
Su macOS, l’overhead della virtualizzazione lo rende un po’ più lento, specialmente per cose intensive sulla CPU come l’esecuzione della suite RSpec in parallelo. Ma per lo sviluppo generale è molto buono.
Non lo uso il 100% delle volte, ma lo uso per piccoli compiti autonomi quando non voglio toccare il mio ambiente di sviluppo principale. Ad esempio: quando controllo il PR di qualcun altro durante una revisione. O se ho bisogno di fare dei test/sviluppo sul branch stable.
Sembra buono! Facci sapere se questo risolve il problema
Oh! Forse devo leggere il manuale. Forse qualcosa è cambiato negli ultimi 5 anni. Forse la prossima volta che mi sentirò frustrato, ci darò un’occhiata. Grazie.
Il comando git clean -f sembra averlo risolto. Ho un fork di Discourse da qualche altra parte che potrei presumibilmente modificare per creare una PR, ma questa copia proviene dalla fonte originale, quindi buttare via eventuali modifiche non è un problema (e probabilmente eventuali modifiche sono state comunque degli incidenti).
Uso principalmente il mio ambiente di sviluppo per lo sviluppo di plugin.
Ora funziona di nuovo e spero con cautela che il mio script funzioni almeno per le prossime volte!
Oggi non sono riuscito ad eseguire il mio ambiente di sviluppo perché Discourse insisteva su pnpm 9.15.5 e npm insisteva sull’installazione di qualcosa di versione 10. ‘pnpm --version’ mi diceva 10.x nella mia home directory, ma si rifiutava di funzionare nella directory di discourse. Ci ho messo tutto il pomeriggio. Alla fine ho disinstallato pnpm con npm e invece ho aggiunto questo al mio script di aggiornamento:
Ho provato a usare la magia di sviluppo di docker, ma non riesco a capire come passarci le ENV, e non ha nemmeno impostato DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE, quindi non ho potuto accedere.
E ora sto di nuovo ricevendo questo:
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
Penso di averlo risolto prima modificando . . . qualcosa.
OK. Ecco come risolvere il problema del nice. Giuro che non capisco come sono l’unico ad essere colpito da questo.
Finché hai questo commit di core, allora in teoria pnpm 10.x dovrebbe automaticamente tornare a pnpm 9 quando eseguito in core. Non dovresti aver bisogno di alcuna tecnica di installazione personalizzata.
Subito dopo il rilascio di pnpm 10, alcuni membri del team hanno avuto problemi e sono stati in grado di risolverli eseguendo pnpm self-update 9. Ma da quando abbiamo aggiunto quella nuova configurazione a core, non credo che nessuno abbia più avuto bisogno di fare nulla manualmente.
Stai usando VSCode? Se stai usando i task predefiniti, allora puoi aggiungere env in tasks.json. Se stai avviando rails/ember tramite il terminale VSCode, allora puoi aggiungere l’env come prefisso come qualsiasi altro terminale.
Questa è una novità per me . Sono contento che tu sia riuscito a risolverlo però!
Sono curioso, quale sistema operativo Linux stai usando?
Sono su d2a34bed8439557bfc37b8c08f89271be6903015 (che dovrebbe essere dopo quello. Ha provato a eseguire pnpm 9, ma non era da nessuna parte che potesse trovarlo, quindi si rifiutava di funzionare perché voleva davvero, davvero, davvero la sua versione. E niente che potessi fare lo avrebbe installato finché non ho preso la faccenda nelle mani di asdf.
Sto usando POP!OS, che pensavo fosse per lo più Ubuntu standard sotto il cofano, ma forse cambiano i valori di renice e sono l’unico a cui è successo. Non ricordo quando è iniziato, ma questa volta l’ho finalmente risolto a livello di sistema operativo e non modificando il core!
