Ember addons are resolving as incorrect peer dependencies. -- fixed by removing "content-tag@3.1.0": "patches/content-tag@3.1.0.patch",

I swear I spend 2-4 hours a week keeping my dev instance working.

I do a 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

And then I removed my plugins and tried again and get this error:


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

I ended up removing this line to make ember work:

Hereā€™s what I do when I pull in a new discourse version:

  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 Likes

Why? That changes the lockfile, which you really donā€™t want to do (unless youā€™re deliberately trying to change Discourseā€™s dependencies). If you donā€™t want to change dependencies, the only pnpm command you should ever need is pnpm install.

The issues youā€™ve described sound like they could be caused if your pnpm lockfile has diverged from coreā€™s. Iā€™d recommend checking for any diff (e.g. via git status, or whatever git GUI you use). If there is a diff, reset it (e.g. via git restore pnpm-lock.yaml)

Possibly related: Iā€™d recommend removing --fix-lockfile from your install script. Coreā€™s lockfile should never need ā€˜fixingā€™, so running this locally is only likely to cause divergence.

BTW have you tried using the devcontainer setup. It aims to almost completely remove this kind of maintenance.

Although admittedly, if this problem is indeed that youā€™ve modified your pnpm lockfile, then it could happen in the devcontainer as well :sweat_smile:

1 Like

Oh, yeahā€¦ thatā€™ll do it :eyes:

Use coreā€™s lockfile. If you delete it and regenerate one from package.json, youā€™ll get the absolute latest version of every dependency, which will definitely cause issues.

Also BTW, pnpm is very good at keeping node_modules in order, so you shouldnā€™t need to delete it every time you pull core. All I do when pulling core is bundle install && pnpm install && bin/rake db:migrate.

Because that fixed the last problem that I had?

Something else that I tried adding today; Iā€™ll remove that one.

I didnā€™t change it on purposeā€¦ It is hard to make things foolproof when fools are so ingenious.

Maybe a git clean -f is what I needed. :person_shrugging:

Not in years. I think I thought it was slower; maybe thatā€™s less true now? Maybe I should try it again? Do you use it?

This is quite a new guide - itā€™s not the same thing as the old ā€œdocker devā€ guide. (in factā€¦ that reminds meā€¦ we should probably deprecate/remove that old guide)

On macOS, the virtualization overhead makes it a little slower, especially for CPU-intensive things like running the RSpec suite in parallel. But for general development itā€™s very good.

I donā€™t use it 100% of the time, but I do use it for small self-contained tasks when I donā€™t want to touch my main development environment. For example: when checking out someone elseā€™s PR during review. Or if I need to do some testing/development on the stable branch.

Sounds good! Let us know if that gets things working :crossed_fingers:

Oh! Maybe I need to RTFM. Maybe something has changed in the past 5 years. Maybe next time I get frustrated Iā€™ll check that out. Thanks.

The git clean -f seems to have fixed it. I do have a fork of Discourse somewhere else that I could ostensibly edit to make a PR, but this copy is from the original source, so throwing away any changes is not a problem (and probably any changes were accidents anyway).

I mostly only ever use my dev environment for plugin development.

Itā€™s working again now, and Iā€™m cautiously hopeful that my script will work for at least the next few times!

2 Likes