Ember 애드온이 잘못된 peer dependencies로 해석됩니다. -- "content-tag@3.1.0": "patches/content-tag@3.1.0.patch"를 제거하여 수정됨,

개발 인스턴스가 정상적으로 작동하도록 유지하는 데 주당 2~4시간을 소비하는 것 같다.

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"
  # 참고: bundler가 깨져 있다면 `gem install bundler -v 2.5.3`을 시도해 보세요

  # 괜찮다. 적어도 데이터베이스를 만드는 것만큼은 우리가 담당할 것이다
  if psql -d discourse_development -c '\q' 2>/dev/null; then
    # 연결 성공
    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 base 컨테이너에서 node 버전 가져오기!
  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

  # 버전 업데이트 종료
  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 lockfile이 코어의 그것과 달라진(diverged) 경우 발생할 수 있는 것 같습니다. 차이점이 있는지 확인해 보시길 권합니다(예: git status나 사용하는 git GUI를 통해). 차이점이 있다면 이를 되돌리세요(예: git restore pnpm-lock.yaml).

관련 사항: 설치 스크립트에서 --fix-lockfile 옵션을 제거하는 것도 추천합니다. 코어의 lockfile은 절대 '수정(fixing)'이 필요하지 않으므로, 로컬에서 이 옵션을 실행하면 오히려 lockfile이 달라지는 문제만 초래할 가능성이 큽니다.

참고로 devcontainer 설정을 사용해 보셨나요? 이 설정은 이러한 종류의 유지보수 작업을 거의 완전히 제거하는 것을 목표로 합니다.

물론 이 문제가 실제로 pnpm lockfile을 수정한 것에서 비롯된 것이라면, devcontainer 환경에서도 같은 문제가 발생할 수 있습니다 :sweat_smile:

아, 그래… 그거면 되겠군 :eyes:

코어(core)의 lockfile을 사용하세요. 이를 삭제하고 package.json에서 다시 생성하면 모든 의존성의 최신 버전이 설치되어 반드시 문제가 발생합니다.

그리고 참고로, pnpmnode_modules를 깔끔하게 관리하는 데 매우 뛰어나므로 코어를 가져올 때마다 삭제할 필요가 없습니다. 저는 코어를 가져올 때 bundle install && pnpm install && bin/rake db:migrate만 실행합니다.

그게 제가 겪었던 마지막 문제를 해결해 주었기 때문인가요?

오늘 추가해 본 다른 내용입니다. 그건 제거하겠습니다.

의도적으로 변경한 것은 아닙니다… 바보들이 그렇게 창의적인데, 바보들이 실수하지 않도록 만드는 것은 어렵습니다.

아마 git clean -f가 필요했던 것 같습니다. :person_shrugging:

수년 동안 사용해 본 적이 없습니다. 더 느리다고 생각했던 것 같습니다. 지금은 그런 게 아닐까요? 다시 시도해 봐야 할까요? 사용하시나요?

이 가이드는 꽤 새로운 버전입니다. 이전의 “docker dev” 가이드와 같은 것이 아닙니다. (사실… 이걸 보니… 그 오래된 가이드를 비추천으로 표시하거나 제거해야 할 것 같네요)

macOS에서는 가상화 오버헤드 때문에 약간 느릴 수 있으며, 특히 RSpec 테스트 스위트를 병렬로 실행하는 것과 같이 CPU 집약적인 작업에서 더 그렇습니다. 하지만 일반적인 개발 작업에는 매우 좋습니다.

100% 항상 사용하지는 않지만, 메인 개발 환경에 영향을 주고 싶지 않을 때 작은 독립적인 작업에는 사용합니다. 예를 들어, 리뷰 중 다른 사람의 PR을 체크아웃할 때나 stable 브랜치에서 테스트/개발을 해야 할 때 등이죠.

좋은 방법입니다! 그게 해결이 되면 알려주세요 :crossed_fingers:

아! 아마도 RTFM(Read The F***ing Manual)을 해야 할 것 같습니다. 지난 5년 사이에 무언가 바뀌었을 수도 있겠네요. 다음에 답답할 때 그걸 확인해 보겠습니다. 감사합니다.

git clean -f가 문제를 해결한 것 같습니다. 다른 곳에 Discourse 포크를 하나 가지고 있어서 PR을 만들려고 ostensibly 편집할 수는 있지만, 이 카피는 원본 소스에서 가져온 것이므로 변경 사항을 모두 폐기하는 것은 문제가 되지 않습니다(아무튼 대부분의 변경 사항은 실수로 인한 것이었을 가능성이 높으니까요).

저는 주로 개발 환경을 플러그인 개발에만 사용합니다.

이제 다시 작동하고 있으며, 내 스크립트가 최소한 앞으로 몇 번은 더 잘 작동할 것이라는 조심스러운 희망을 가지고 있습니다!

오늘 디스코urses 개발 환경을 실행하지 못했습니다. Discourse는 pnpm 9.15.5를 요구했고, npm은 10.x 버전을 설치하려 했기 때문입니다. 홈 디렉터리에서 pnpm --version을 실행하면 10.x 버전이 표시되었지만, discourse 디렉터리에서는 실행을 거부했습니다. 오후 내내 이 문제를 해결하느라 시간을 보냈습니다. 결국 npm으로 pnpm을 제거하고, 업데이트 스크립트에 다음 내용을 추가했습니다:

  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"

이렇게 하니 잘 작동하는 것 같습니다.

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에 env를 추가할 수 있습니다. VSCode 터미널을 통해 rails/ember를 실행 중이라면, 다른 터미널과 마찬가지로 env를 접두사로 추가할 수 있습니다.

저에게는 새로운 문제네요 :sweat_smile:. 그래도 해결하셨다니 다행입니다!

궁금한 것이 있는데, 어떤 리눅스 운영체제를 사용 중이신가요?

저는 d2a34bed8439557bfc37b8c08f89271be6903015를 사용 중입니다(그 커밋 이후여야 합니다). pnpm 9 실행을 시도했지만, 찾을 수 있는 어디에도 없었기 때문에, pnpm 9는 정말로, 정말로, 정말로 자기 자신의 버전을 원해서 실행을 거부했습니다. 제가 asdf를 직접적으로 개입시키지 않는 한 아무것도 설치되지 않았습니다.

아, 정말요. 아니요, 전혀요. "development docker"를 검색했는데, 아마도 오래된 방식을 찾은 것 같습니다: Install Discourse for development using Docker. 만약 이것이 현재 우리가 선호하는 방식이라면, Developing Discourse using a Dev Container 링크를 연결해 주실 수 있을까요?

저는 POP!OS를 사용 중인데, 내부적으로는 대부분 표준 Ubuntu일 것이라 생각했지만, 아마도 renice 값을 변경했을 수도 있고, 이 문제가 저에게만 발생한 것일 수도 있습니다. 언제부터 시작되었는지 기억나지 않지만, 이번에는 코어를 수정하는 것이 아니라 OS 레벨에서 마침내 문제를 해결했습니다!