Juro que passo de 2 a 4 horas por semana mantendo minha instância de desenvolvimento funcionando.
Eu rodo 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
[quote=“Jay Pfaffman, post:1, topic:350251, username:pfaffman”]
Eu faço um pnpm dedupe.
[/quote]Por quê? Isso altera o lockfile, o que você realmente não quer fazer (a menos que esteja deliberadamente tentando alterar as dependências do Discourse). Se você não quiser alterar as dependências, o único comando pnpm que você deve precisar é pnpm install.
Os problemas que você descreveu podem ser causados se seu pnpm lockfile divergiu do core. Recomendo verificar se há alguma diferença (por exemplo, via git status, ou qualquer GUI git que você use). Se houver uma diferença, restaure-a (por exemplo, via git restore pnpm-lock.yaml)
Possivelmente relacionado: recomendo remover --fix-lockfile do seu script de instalação. O lockfile do core nunca deve precisar de “correção”, então executá-lo localmente só provavelmente causará divergência.
A propósito, você já tentou usar a configuração do devcontainer. Ele visa remover quase completamente esse tipo de manutenção.
Embora, admitidamente, se este problema for de fato que você modificou seu pnpm lockfile, então ele também pode acontecer no devcontainer
Use o lockfile do core. Se você o excluir e regenerar um a partir do package.json, obterá a versão mais recente de cada dependência, o que definitivamente causará problemas.
Além disso, o pnpm é muito bom em manter o node_modules em ordem, então você não deve precisar excluí-lo toda vez que fizer o pull do core. Tudo o que eu faço ao fazer o pull do core é bundle install && pnpm install && bin/rake db:migrate.
Este é um guia bem novo - não é a mesma coisa que o antigo guia “docker dev”. (na verdade… isso me lembra… provavelmente deveríamos depreciar/remover esse guia antigo)
No macOS, a sobrecarga de virtualização o torna um pouco mais lento, especialmente para coisas intensivas em CPU, como executar o conjunto RSpec em paralelo. Mas para desenvolvimento geral, é muito bom.
Eu não o uso 100% do tempo, mas o uso para tarefas pequenas e autônomas quando não quero mexer no meu ambiente de desenvolvimento principal. Por exemplo: ao verificar o PR de outra pessoa durante a revisão. Ou se eu precisar fazer algum teste/desenvolvimento no branch stable.
Ah! Talvez eu precise ler o manual. Talvez algo tenha mudado nos últimos 5 anos. Talvez da próxima vez que eu ficar frustrado, eu vá verificar isso. Obrigado.
O git clean -f parece ter resolvido. Eu tenho um fork do Discourse em algum lugar que eu poderia, ostensivamente, editar para fazer um PR, mas esta cópia é da fonte original, então jogar fora quaisquer alterações não é um problema (e provavelmente quaisquer alterações foram acidentes de qualquer maneira).
Eu uso principalmente meu ambiente de desenvolvimento para desenvolvimento de plugins.
Está funcionando novamente agora, e estou cautelosamente esperançoso de que meu script funcione pelo menos pelas próximas vezes!
Hoje não consegui executar meu ambiente de desenvolvimento porque o Discourse insistia em pnpm 9.15.5 e o npm insistia em instalar a versão 10. Algo. ‘pnpm --version’ me dizia 10.x no meu diretório pessoal, mas se recusava a rodar no diretório do Discourse. Levou a tarde toda. Finalmente desinstalei o pnpm com npm e, em vez disso, adicionei isso ao meu script de atualização:
PNPM_VERSION=$(docker run discourse/base:release bash -c 'pnpm --version'|cut -d'v' -f2)
echo "PEGUEI a versão do PNPM: $PNPM_VERSION"
asdf install pnpm $PNPM_VERSION 2>&1|grep -v "already"
asdf global pnpm $PNPM_VERSION 2>&1|grep -v "already"
Isso parece funcionar.
Tentei usar a mágica de desenvolvimento do Docker, mas não consigo descobrir como passar variáveis de ambiente para ela, e ela nem sequer tem DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE definida, então não consegui fazer login.
E agora estou recebendo isso novamente:
Erro encontrado ao iniciar o 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
Acho que consertei isso antes editando… algo.
Ok. Aqui está como consertar a coisa do nice. Juro que não entendo como sou o único a ser atingido por isso.
Desde que você tenha este commit do core, então, em teoria, o pnpm 10.x deve automaticamente voltar para o pnpm 9 quando executado no core. Você não deve precisar de nenhuma técnica de instalação personalizada.
Imediatamente após o lançamento do pnpm 10, alguns membros da equipe tiveram problemas e conseguiram resolvê-los executando pnpm self-update 9. Mas, desde que adicionamos essa nova configuração ao core, acho que ninguém precisou fazer nada manualmente.
Usando o VSCode? Se você estiver usando as tarefas predefinidas, poderá adicionar variáveis de ambiente em tasks.json. Se você estiver iniciando o Rails/Ember pelo terminal do VSCode, poderá adicionar as variáveis de ambiente como um prefixo, como em qualquer outro terminal.
Essa é nova para mim . Que bom que você conseguiu resolver!
Estou curioso, qual sistema operacional Linux você está executando?
Estou no d2a34bed8439557bfc37b8c08f89271be6903015 (que deve ser posterior a isso. Ele tentou executar o pnpm 9, mas não o encontrou em lugar nenhum, então se recusou a executar porque realmente, realmente, realmente queria sua própria versão. E nada que eu pudesse fazer o instalaria até que eu tomasse as providências com o asdf.
Estou executando o POP!OS, que eu achava que era majoritariamente Ubuntu padrão por baixo, mas talvez eles mudem os valores de renice e eu sou o único a quem isso aconteceu. Não me lembro quando começou, mas desta vez finalmente o consertei no nível do sistema operacional e não editando o core!