Аддоны Ember определяются как неверные пир-зависимости. -- исправлено удалением "content-tag@3.1.0": "patches/content-tag@3.1.0.patch",

Клянусь, я трачу 2–4 часа в неделю на то, чтобы мой dev-инстанс оставался рабочим.

Я выполняю 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

Затем я удалил свои плагины и попытался снова, но получил эту ошибку:


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

В итоге я удалил эту строку, чтобы заставить Ember работать:

Вот что я делаю при обновлении до новой версии 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 -dv' ' -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

Зачем? Это изменяет файл блокировки (lockfile), чего вам действительно не следует делать (если только вы не намеренно пытаетесь изменить зависимости Discourse). Если вы не хотите менять зависимости, единственная команда pnpm, которая вам когда-либо понадобится, — это pnpm install.

Описанные вами проблемы могут быть вызваны тем, что ваш файл блокировки pnpm разошелся с файлом блокировки ядра (core). Рекомендую проверить наличие каких-либо различий (например, через git status или любой графический интерфейс Git, который вы используете). Если различия есть, отмените их (например, через git restore pnpm-lock.yaml).

Возможно, это связано с чем-то другим: рекомендую убрать --fix-lockfile из вашего скрипта установки. Файл блокировки ядра никогда не должен нуждаться в «исправлении», поэтому запуск этого локально скорее всего приведет к расхождению.

Кстати, пробовали ли вы использовать настройку devcontainer? Она направлена на почти полное устранение такого рода обслуживания.

Хотя, признаюсь, если проблема действительно в том, что вы изменили свой файл блокировки pnpm, то это может произойти и в devcontainer :sweat_smile:

Ага, точно… это поможет :eyes:

Используйте файл блокировки из core. Если вы удалите его и сгенерируете новый на основе package.json, вы получите абсолютно последние версии всех зависимостей, что обязательно вызовет проблемы.

Кстати, pnpm отлично справляется с поддержкой порядка в node_modules, поэтому вам не нужно удалять его каждый раз при обновлении core. Всё, что я делаю при обновлении core, это bundle install && pnpm install && bin/rake db:migrate.

Потому что это устранило последнюю проблему, с которой я столкнулся?

Ещё одна вещь, которую я сегодня попробовал добавить; я уберу и это.

Я не менял его намеренно… Трудно сделать что-то неуязвимым для ошибок, когда глупцы так изобретательны.

Возможно, мне нужно было выполнить git clean -f. :person_shrugging:

Не использовал уже много лет. Мне казалось, что это работает медленнее; может быть, сейчас это уже не так? Может, стоит попробовать снова? Вы его используете?

Это довольно новое руководство — оно не то же самое, что старое руководство «docker dev». (Кстати… это напомнило… нам, наверное, стоит устареть/удалить то старое руководство)

В macOS накладные расходы виртуализации делают работу немного медленнее, особенно для задач, требующих много процессорного времени, таких как параллельный запуск набора тестов RSpec. Но для общей разработки это очень хорошо.

Я не использую его 100% времени, но применяю для небольших изолированных задач, когда не хочу трогать свою основную среду разработки. Например: при проверке чужого PR во время ревью. Или если мне нужно провести тестирование/разработку на ветке stable.

Звучит отлично! Дайте знать, если это поможет всё исправить :crossed_fingers:

О! Возможно, мне стоит перечитать документацию (RTFM). Может быть, за последние 5 лет что-то изменилось. В следующий раз, когда я расстроюсь, я обязательно это проверю. Спасибо.

Команда git clean -f, похоже, исправила проблему. У меня где-то есть форк Discourse, который теоретически можно отредактировать для создания запроса на слияние (PR), но эта копия взята из оригинального источника, поэтому отбрасывание любых изменений не является проблемой (да и любые изменения, вероятно, были случайными).

Я в основном использую свою среду разработки только для создания плагинов.

Теперь всё работает, и я с осторожным оптимизмом надеюсь, что мой скрипт будет работать как минимум ещё несколько раз!

Сегодня я не мог запустить свою dev-среду, потому что Discourse настаивал на pnpm 9.15.5, а npm пытался установить версию 10.x. Команда pnpm --version в моей домашней директории показывала 10.x, но отказывалась работать в директории discourse. Это заняло у меня всё afternoon. В итоге я удалил pnpm через npm и добавил следующее в свой скрипт обновления:

  PNPM_VERSION=$(docker run discourse/base:release bash -c 'pnpm --version'|cut -d'v' -f2)
  echo "Получена версия PNPM: $PNPM_VERSION"
  asdf install pnpm $PNPM_VERSION 2>&1|grep -v "already"
  asdf global pnpm $PNPM_VERSION 2>&1|grep -v "already"

Кажется, это работает.

Я пробовал использовать docker-магию для разработки, но не понял, как передать в неё переменные окружения (ENV), и в ней даже не установлен DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE, поэтому я не мог войти в систему.

А теперь у меня снова возникла эта ошибка:

 Error encountered while starting Sidekiq: [Discourse::Utils::CommandError] /home/pfaffman/src/discourse-r
epos/discourse/lib/discourse.rb:139:in `exec': renice: failed to set priority for 116553 (process ID): Permission denied   

Кажется, я уже исправлял это раньше, отредактировав . . . что-то.

Хорошо, вот как исправить проблему с nice. Клянусь, я не понимаю, почему я единственный, с кем это происходит.

В файле, например:

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

Добавьте что-то вроде:

pfaffman soft priority 5
pfaffman hard priority 5

Если у вас есть этот коммит ядра, то теоретически pnpm 10.x должен автоматически переключаться на pnpm 9 при запуске в ядре. Вам не понадобятся какие-либо специальные методы установки.

Сразу после выхода pnpm 10 у некоторых участников команды возникли проблемы, которые удалось решить, выполнив команду pnpm self-update 9. Но поскольку мы добавили эту новую конфигурацию в ядро, я не думаю, что кому-либо приходилось что-то делать вручную.

Используете ли вы VSCode? Если вы используете предопределённые задачи, то можете добавить переменные окружения в tasks.json. Если вы запускаете rails/ember через терминал VSCode, то можете добавить переменные окружения как префикс, как в любом другом терминале.

Для меня это что-то новое :sweat_smile:. Но рад, что вам удалось это решить!

Мне интересно, какую операционную систему Linux вы используете?

У меня версия d2a34bed8439557bfc37b8c08f89271be6903015 (которая должна быть новее того коммита). Оно пыталось запустить pnpm 9, но не могло его нигде найти, поэтому отказывалось запускаться, потому что очень-очень-очень хотело свою собственную версию. И ничего из того, что я пробовал, не устанавливало его, пока я не перепоручил это asdf.

Ого. Черт. Нет. Я искал «development docker» и, кажется, нашёл старый способ: Install Discourse for development using Docker. Не мог бы кто-нибудь, возможно, дать ссылку на Developing Discourse using a Dev Container, если это то, что мы теперь используем?

Я использую POP!OS. Я думал, что это по сути обычный Ubuntu, но, возможно, они изменили значения renice, и я единственный, с кем это произошло. Не помню, когда это началось, но в этот раз я наконец исправил это на уровне ОС, а не путём редактирования ядра!