feat: peerDependencies 호환성 검증 단계 추가

[yujeong-jeon]

Related Issue

• feat: add package-evaluator plugin (0.x experimental) #15

Describe your changes

패키지 도입 평가 프로세스에 peerDependencies 호환성 확인 단계를 추가합니다.

• 평가 프로세스 3단계로 peerDependencies 호환성 확인 추가 (npm/Bun/Deno 매니페스트 대응)
• 즉시 거부 조건에 peer 버전 불일치 추가
• 경고 조건에 필수 peer 미설치 추가
• peerDependenciesMeta의 optional: true 처리

Request

• peerDependencies 검증 기준이 적절한지 확인 부탁드립니다

[yceffort-naver]

이거 킥이네요.. 역시 책 저자다운...

[yujeong-jeon]

틈틈히 기억을 살리려 읽어야 하는..

[yujeong-jeon]

@claude 이 PR 리뷰 해줘. peerDependencies를 고려한 3rd-party 설치 검증이야.

[claude]

Claude finished @yujeong-jeon's task in 1m 25s —— View job

---

PR 리뷰: peerDependencies 호환성 검증 추가

• 컨텍스트 파악
• 변경 파일 읽기
• 리뷰 작성

---

개요

evaluate-package.md 슬래시 커맨드에 3rd-party 패키지의 peerDependencies 호환성을 검증하는 3단계를 추가한 PR입니다. 설계 방향(버전 불일치 → 즉시 거부, 미설치 → 경고, optional → 무시)은 실무적으로 적절합니다.

---

잘된 점 ✅

• 3단계 분류 기준이 명확합니다: 버전 불일치(거부) / 필수 미설치(경고) / optional(무시) 구분이 npm의 동작 방식과 일치합니다.
• 다양한 패키지 매니저 대응: npm/yarn/pnpm, Bun, Deno 환경을 모두 열거한 점이 실용적입니다.
• 단계 순서가 논리적입니다: peer 호환성 검사를 GitHub 이슈 분석(비교적 느린 단계) 전에 배치해, 빠른 거부가 가능합니다.

---

개선 제안

1. peerDependenciesMeta 조회 명령어 누락

현재 bash 커맨드는 peerDependencies만 조회합니다.

npm view <패키지명> peerDependencies --json

하지만 선택적 peer 처리(optional: true 무시)를 위해서는 peerDependenciesMeta도 함께 조회해야 합니다. 두 정보가 분리된 npm 필드이므로 명시적으로 추가하는 것이 좋습니다.

# 대상 패키지의 peerDependencies 및 optional 여부 조회
npm view <패키지명> peerDependencies peerDependenciesMeta --json

Fix this →

---

2. 설치 버전 확인 방법: package.json vs 실제 resolved 버전

package.json의 dependencies에는 "react": "^18.0.0" 같은 semver 범위가 기록되어 있습니다. 하지만 peer 호환성 검사는 실제 설치된 정확한 버전을 기준으로 해야 더 정확합니다.

예: 패키지가 peerDependencies: { "react": ">=19" }를 요구하는데, 프로젝트 package.json에 "react": "^18.0.0"이 있다면 → 범위 레벨에서도 비호환이 명확하지만, "react": ">=16"처럼 느슨한 범위를 가진 경우엔 실제 설치 버전(예: 16.14.0)과 비교해야 정확합니다.

아래 명령어로 실제 설치 버전을 확인하는 방법을 추가하면 더 신뢰도가 높아집니다:

# 실제 설치된 버전 확인 (lockfile 기반)
npm ls <peer-패키지명> --json 2>/dev/null | node -e "const d=require('/dev/stdin'); console.log(JSON.stringify(d?.dependencies))"

---

3. Deno 환경에서의 버전 추출 모호성

deno.json의 imports 필드는 "react": "npm:react@^18.0.0" 형태의 URL 기반 표현을 사용합니다. 이 경우 semver 범위 추출이 일반 package.json과 방법이 다르므로, 구체적인 파싱 방법을 명시하면 Claude가 올바르게 처리할 수 있습니다.

- `deno.json` 또는 `deno.jsonc` 존재 시 Deno 환경:  
  `imports` 필드의 `npm:<패키지명>@<버전>` 패턴에서 버전 추출

---

4. 출력 형식에 peerDependencies 결과 섹션 없음

현재 단일 패키지 평가 출력 예시(line 156–160)에는 peerDependencies 확인 결과가 포함되어 있지 않습니다.

🔍 기존 설치 패키지 확인
- 동일/유사 패키지: 해당 없음

peerDependencies 검사가 3단계로 추가되었으니, 출력 형식에도 해당 결과를 표시하는 섹션을 추가하면 사용자 입장에서 무슨 검사가 이루어졌는지 파악하기 쉽습니다:

🔗 peerDependencies 호환성
- react: ^18.0.0 → 프로젝트 설치: 18.3.1 ✅
- react-dom: ^18.0.0 → 미설치 ⚠️

---

검증 기준 적절성 평가 (PR 요청사항)

기준	판단	비고
버전 불일치 → 즉시 거부	✅ 적절	런타임 오류 위험
필수 peer 미설치 → 경고	✅ 적절	도입 자체는 가능하나 추가 작업 필요
optional peer 미설치 → 무시	✅ 적절	npm spec과 일치
Bun/Deno 환경 대응	✅ 방향 맞음	Deno 파싱 방법만 보완 필요

전반적으로 기준 설계는 적절합니다. 위 제안은 엣지케이스 대응과 출력 완성도를 높이기 위한 것이며, 핵심 로직 자체는 문제 없습니다.

---

[claude]

⚠️ Code review skipped — your organization's overage spend limit has been reached.

Code review is billed via overage credits. To resume reviews, an organization admin can raise the monthly limit in Settings → Usage.

Once credits are available, push a new commit or reopen this pull request to trigger a review.

[yujeong-jeon]

3. Deno 환경에서의 버전 추출 모호성

뺴고 반영. Deno 환경 분석을 모르면 agent가 아닌.. 읍읍

[yujeong-jeon]

@yceffort-naver 듀? 용찬님 혹시 usage 확인을 위해 사용하신 api key 문의드립니다 😮

[yceffort-naver]

@yujeong-jeon #17 (comment) 요건 키가 아니고 별도로 설정을 키는거더라구요..!

https://www.reddit.com/r/ycombinator/comments/1rqwjp2/claude_code_review_is_1525pr_does_that_make_sense/
근데 이거 너무 비싸서 끌예정...

그냥 저 리뷰정도면 괜찮을거같은데 어떻게 보시나요?

[yceffort-naver]

LGTM

[yujeong-jeon]

네넹! 저도 직접 호출하는 편으로 우선 쓰고 싶슴다!

++ 근데 쓸데없이 장점 나열 킹받아서 시스템 프롬프트라도 넣어야겠음 (검증은 좋은데 0ㄱ0)