Juro que passo 2 a 4 horas por semana mantendo minha instância de desenvolvimento funcionando.
Eu faço um 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 então removi meus plugins e tentei novamente e recebi este erro:
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
Acabei removendo esta linha para fazer o ember funcionar:
Aqui está o que eu faço quando puxo uma nova versão do 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
¿Por qué? Eso cambia el archivo de bloqueo, lo cual realmente no quieres hacer (a menos que estés intentando cambiar deliberadamente las dependencias de Discourse). Si no quieres cambiar las dependencias, el único comando de pnpm que deberías necesitar es pnpm install.
Los problemas que has descrito podrían ser causados si tu archivo de bloqueo de pnpm se ha desviado del núcleo. Te recomiendo comprobar si hay alguna diferencia (por ejemplo, a través de git status, o cualquier GUI de git que uses). Si hay una diferencia, restáurala (por ejemplo, a través de git restore pnpm-lock.yaml).
Posiblemente relacionado: Te recomiendo eliminar --fix-lockfile de tu script de instalación. El archivo de bloqueo del núcleo nunca debería necesitar ser “arreglado”, por lo que ejecutar esto localmente solo podría causar divergencia.
Por cierto, ¿has intentado usar la configuración de devcontainer? Pretende eliminar casi por completo este tipo de mantenimiento.
Aunque, seamos sinceros, si este problema es realmente que has modificado tu archivo de bloqueo de pnpm, entonces podría ocurrir también en el devcontainer
Usa el lockfile de core. Si lo eliminas y regeneras uno a partir de package.json, obtendrás la versión más reciente de cada dependencia, lo que definitivamente causará problemas.
Además, por cierto, pnpm es muy bueno para mantener node_modules en orden, por lo que no deberías necesitar eliminarlo cada vez que extraigas core. Todo lo que hago al extraer core es bundle install && pnpm install && bin/rake db:migrate.
Esta es una guía bastante nueva; no es lo mismo que la antigua guía “docker dev”. (de hecho… eso me recuerda… probablemente deberíamos desaprobar/eliminar esa antigua guía)
En macOS, la sobrecarga de virtualización lo hace un poco más lento, especialmente para cosas intensivas en CPU como ejecutar el conjunto RSpec en paralelo. Pero para el desarrollo general es muy bueno.
No lo uso el 100% del tiempo, pero sí lo uso para tareas pequeñas y autocontenidas cuando no quiero tocar mi entorno de desarrollo principal. Por ejemplo: al revisar el PR de otra persona durante una revisión. O si necesito hacer algunas pruebas/desarrollo en la rama stable.
¡Suena bien! Háganos saber si eso soluciona las cosas
¡Oh! Quizás necesite leer el manual (RTFM). Quizás algo haya cambiado en los últimos 5 años. Quizás la próxima vez que me frustre, lo consulte. Gracias.
El git clean -f parece haberlo solucionado. Tengo una bifurcación de Discourse en otro lugar que ostensiblemente podría editar para hacer una PR, pero esta copia es de la fuente original, por lo que desechar cualquier cambio no es un problema (y probablemente cualquier cambio fue un accidente de todos modos).
Principalmente solo uso mi entorno de desarrollo para el desarrollo de complementos.
Está funcionando de nuevo y albergo la esperanza cautelosa de que mi script funcione al menos las próximas veces.
Hoy no pude ejecutar mi entorno de desarrollo porque Discourse insistía en pnpm 9.15.5 y npm insistía en instalar la versión 10. Algo. ‘pnpm --version’ me decía 10.x en mi directorio de inicio, pero se negaba a ejecutarse en el directorio de Discourse. Me llevó toda la tarde. Finalmente, terminé desinstalando pnpm con npm y en su lugar agregué esto a mi script de actualización:
PNPM_VERSION=$(docker run discourse/base:release bash -c 'pnpm --version'|cut -d'v' -f2)
echo "TENGO la versión de PNPM: $PNPM_VERSION"
asdf install pnpm $PNPM_VERSION 2>&1|grep -v "already"
asdf global pnpm $PNPM_VERSION 2>&1|grep -v "already"
Eso parece funcionar.
Intenté usar la magia de desarrollo de Docker, pero no pude averiguar cómo pasarle variables de entorno (ENV) y ni siquiera tenía DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE configurada, por lo que no pude iniciar sesión.
Y ahora estoy volviendo a recibir esto:
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
Creo que lo arreglé antes editando… algo.
OK. Aquí está cómo arreglar lo de nice. Juro que no entiendo cómo soy el único afectado por esto.
Siempre que tengas este commit en core, entonces en teoría pnpm 10.x debería volver automáticamente a pnpm 9 cuando se ejecute en core. No deberías necesitar ninguna técnica de instalación personalizada.
Inmediatamente después del lanzamiento de pnpm 10, algunos miembros del equipo tuvieron problemas y pudieron resolverlos ejecutando pnpm self-update 9. Pero desde que agregamos esa nueva configuración a core, no creo que nadie haya necesitado hacer nada manualmente.
¿Usas VSCode? Si estás usando las tareas predefinidas, puedes agregar variables de entorno en tasks.json. Si estás ejecutando rails/ember a través de la terminal de VSCode, puedes agregar la variable de entorno como un prefijo como en cualquier otra terminal.
Esa es nueva para mí . ¡Me alegro de que hayas logrado resolverlo!
Tengo curiosidad, ¿qué sistema operativo Linux estás ejecutando?
Estoy en d2a34bed8439557bfc37b8c08f89271be6903015 (que debería ser posterior a eso. Intentó ejecutar pnpm 9, pero no estaba en ningún lugar donde pudiera encontrarlo, por lo que se negaría a ejecutarse porque realmente, realmente, realmente quería su propia versión. Y nada de lo que pude hacer lo instaló hasta que tomé el asunto en manos de asdf.
Estoy ejecutando POP!OS, que pensé que era en su mayoría Ubuntu estándar bajo el capó, pero tal vez cambian los valores de renice y soy el único al que le ha sucedido esto. No recuerdo cuándo comenzó, pero esta vez finalmente lo arreglé a nivel del sistema operativo y no editando el core.
