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

Dev
1

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
2

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
3

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.

4

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?

5

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:

6

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
7

Today I couldnā€™t run my dev environment because Discourse insisted on pnpm 9.15.5 and npm insisted on installing 10 something. ā€˜pnpm --versionā€™ would tell me 10.x in my home directory, but would refuse to run in the discourse directory. It took all afternoon. I finally ended up uninstalling pnpm with npm and instead adding this to my update script:

  PNPM_VERSION=$(docker run discourse/base:release bash -c 'pnpm --version'|cut -d'v' -f2)
  echo "GOT PNPM version: $PNPM_VERSION"
  asdf install pnpm $PNPM_VERSION 2>&1|grep -v "already"
  asdf global pnpm $PNPM_VERSION 2>&1|grep -v "already"

That seems to work.

I tried using the docker development magic, but I canā€™t figure out how to pass ENV to it, and it doesnā€™t even have DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE set, so I couldnā€™t log in.

And now Iā€™m getting this again:

 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

I think I fixed it before by editing . . . something.

OK. Hereā€™s what to fix the nice thing. I swear I donā€™t see how Iā€™m the only one hit by this.

In a file like

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

Add something like

pfaffman soft priority 5
pfaffman hard priority 5
1 Like
8

As long as you have this commit of core, then in theory pnpm 10.x should automatically drop back to pnpm 9 when run in core. You shouldnā€™t need any custom install technique.

Immediately after the pnpm 10 release, some team members did have problems, and were able to resolve by running pnpm self-update 9. But since we added that new config to core, I donā€™t think anyone has needed to do anything manually.

Using VSCode? If youā€™re using the predefined tasks, then you can add env in tasks.json. If youā€™re launching rails/ember via the VSCode terminal, then you can add the env as a prefix like any other terminal.

Thatā€™s a new one for me :sweat_smile:. Glad you managed to solve it though!

Iā€™m curious, what linux OS are you running?

9

Iā€™m on d2a34bed8439557bfc37b8c08f89271be6903015 (which should be after that. It tried to run pnpm 9, but it wasnā€™t anywhere that it could find it, so it would refuse to run because it really, really really wanted its own version. And nothing that I could do would install it until I took matters into asdfā€™s hands.

Golly. Heck. No. I searched for ā€œdevelopment dockerā€ and I guess got the old way: Install Discourse for development using Docker. Could someone maybe link it to Developing Discourse using a Dev Container if thatā€™s what we like now?

Iā€™m running POP!OS, which I thought was mostly stock Ubuntu under the hood, but maybe they change the renice values and I am the only one this has happened to. I canā€™t remember when it started, but this time I finally fixed it at the OS level and not by editing core!

2 Likes