Клянусь, я трачу 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
Используйте файл блокировки из core. Если вы удалите его и сгенерируете новый на основе package.json, вы получите абсолютно последние версии всех зависимостей, что обязательно вызовет проблемы.
Кстати, pnpm отлично справляется с поддержкой порядка в node_modules, поэтому вам не нужно удалять его каждый раз при обновлении core. Всё, что я делаю при обновлении core, это bundle install && pnpm install && bin/rake db:migrate.
Потому что это устранило последнюю проблему, с которой я столкнулся?
Ещё одна вещь, которую я сегодня попробовал добавить; я уберу и это.
Я не менял его намеренно… Трудно сделать что-то неуязвимым для ошибок, когда глупцы так изобретательны.
Возможно, мне нужно было выполнить git clean -f.
Не использовал уже много лет. Мне казалось, что это работает медленнее; может быть, сейчас это уже не так? Может, стоит попробовать снова? Вы его используете?
Это довольно новое руководство — оно не то же самое, что старое руководство «docker dev». (Кстати… это напомнило… нам, наверное, стоит устареть/удалить то старое руководство)
В macOS накладные расходы виртуализации делают работу немного медленнее, особенно для задач, требующих много процессорного времени, таких как параллельный запуск набора тестов RSpec. Но для общей разработки это очень хорошо.
Я не использую его 100% времени, но применяю для небольших изолированных задач, когда не хочу трогать свою основную среду разработки. Например: при проверке чужого PR во время ревью. Или если мне нужно провести тестирование/разработку на ветке stable.
Звучит отлично! Дайте знать, если это поможет всё исправить
О! Возможно, мне стоит перечитать документацию (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. Клянусь, я не понимаю, почему я единственный, с кем это происходит.
Если у вас есть этот коммит ядра, то теоретически pnpm 10.x должен автоматически переключаться на pnpm 9 при запуске в ядре. Вам не понадобятся какие-либо специальные методы установки.
Сразу после выхода pnpm 10 у некоторых участников команды возникли проблемы, которые удалось решить, выполнив команду pnpm self-update 9. Но поскольку мы добавили эту новую конфигурацию в ядро, я не думаю, что кому-либо приходилось что-то делать вручную.
Используете ли вы VSCode? Если вы используете предопределённые задачи, то можете добавить переменные окружения в tasks.json. Если вы запускаете rails/ember через терминал VSCode, то можете добавить переменные окружения как префикс, как в любом другом терминале.
Для меня это что-то новое . Но рад, что вам удалось это решить!
Мне интересно, какую операционную систему Linux вы используете?
У меня версия d2a34bed8439557bfc37b8c08f89271be6903015 (которая должна быть новее того коммита). Оно пыталось запустить pnpm 9, но не могло его нигде найти, поэтому отказывалось запускаться, потому что очень-очень-очень хотело свою собственную версию. И ничего из того, что я пробовал, не устанавливало его, пока я не перепоручил это asdf.
Я использую POP!OS. Я думал, что это по сути обычный Ubuntu, но, возможно, они изменили значения renice, и я единственный, с кем это произошло. Не помню, когда это началось, но в этот раз я наконец исправил это на уровне ОС, а не путём редактирования ядра!