Addons do Ember estão sendo resolvidos como dependências de pares incorretas. -- resolvido removendo "content-tag@3.1.0": "patches/content-tag@3.1.0.patch"

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
2 curtidas

[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 :sweat_smile:

1 curtida

Ah, sim… isso vai resolver :eyes:

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.

Porque isso resolveu o último problema que eu tive?

Algo mais que eu tentei adicionar hoje; vou remover isso.

Eu não o alterei de propósito… É difícil tornar as coisas à prova de falhas quando os tolos são tão engenhosos.

Talvez um git clean -f fosse o que eu precisava. :person_shrugging:

Não em anos. Acho que pensei que era mais lento; talvez isso seja menos verdade agora? Talvez eu devesse tentar novamente? Você o usa?

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.

Parece bom! Nos diga se isso resolve o problema :crossed_fingers:

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!

2 curtidas

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.

Em um arquivo como

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

Adicione algo como

pfaffman soft priority 5
pfaffman hard priority 5
1 curtida

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 :sweat_smile:. 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.

Nossa. Que. Não. Pesquisei por “development docker” e acho que peguei o jeito antigo: Install Discourse for development using Docker. Alguém poderia, por favor, vinculá-lo a Developing Discourse using a Dev Container se é isso que preferimos agora?

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!

2 curtidas