Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![pr-agent-demo[bot]](https://avatars.githubusercontent.com/in/3949189?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
이 PR은 monorepo 전반에서 보안 권고가 보고된 프로덕션 의존성(next, axios, @sentry/nextjs)을 패치된 버전으로 상향합니다. 또한 packages/api, packages/ui의 next peer 범위를 강화해 취약 버전이 잠금 파일에 남지 않도록 했고, Sentry Next.js 10.78에 맞춘 config import 경로도 변경합니다.
Intent
주된 목적은 pnpm audit --prod에서 드러난 critical/high 보안 권고를 줄이고, workspace 전반에서 Next.js 및 Sentry 관련 버전 일관성을 유지하는 것입니다. 메이저 업그레이드 없이 최신 patch/minor 버전으로 올리는 방식으로 보입니다.
Risk
전체적으로 중간~중상 수준의 업그레이드 리스크가 있습니다. Next.js 16.x patch 상승이 client/admin 빌드, 이미지 최적화, React Compiler, Sentry config에 영향을 줄 수 있습니다. pnpm-lock.yaml 변경량이 크고 peer 범위 변경으로 인해 auto-install-peers 동작이나 workspace 간 버전 정합성도 확인이 필요합니다. 배포 후 Vercel 환경에서의 실제 Sentry 수집 및 이미지 처리 동작 검증이 중요합니다.
5 inline comment(s)
yeondon125
left a comment
yeondon125
left a comment
There was a problem hiding this comment.
PR 본문의 작업내용 표와 설명이 최종 diff와 맞지 않습니다.
- 표에
next(peer 범위)^16.0.0→^16.4.6(packages/api,packages/ui) 행이 남아 있습니다. 하지만 ee401a3에서 peer 범위를^16.0.0으로 되돌렸기 때문에, 지금 diff에는 이 변경이 없습니다. - 실제로 들어간 루트
pnpm.overrides의"next": "^16.4.6"은 본문에 나오지 않습니다.
이후에 이 PR을 참고하는 사람이 잘못된 방식을 따라가지 않도록, 표와 설명을 override 기준으로 고쳐 주시면 좋겠습니다.
| "@types/react": "^19.2.17", | ||
| "@types/react-dom": "^19.2.3" | ||
| "@types/react-dom": "^19.2.3", | ||
| "next": "^16.4.6" |
There was a problem hiding this comment.
이 override에는 버전 조건이 없어서, 취약한 버전만이 아니라 workspace 안의 모든 next가 계속 ^16.4.6(16.x)으로 고정됩니다.
- 나중에
apps/client·apps/admin을"next": "^17.0.0"으로 올려도 pnpm이 이 override를 적용해서 경고 없이 16.x를 설치합니다. package.json만 보면 업그레이드가 끝난 것처럼 보이기 때문에 알아채기 어렵습니다. - 다른 패키지의 peer 범위도 함께 덮어씁니다. 잠금 파일 2832–2836행에서
@sentry/nextjs@10.78.0의 peer가next: ^16.4.6로 기록되어 있는데, 실제로 배포된 범위는^13.2.0 || ^14.0 || ^15.0.0-rc.0 || ^16.0.0-0입니다. 그래서 앞으로 Sentry와next사이의 peer 경고가 제대로 뜨지 않을 수 있습니다.
취약한 범위만 올리도록 selector를 지정하는 건 어떨까요?
"next@<16.4.6": "^16.4.6"아니면 원인이 auto-install-peers가 잠금 파일에 남긴 옛 16.2.10 해석이었으니, override 없이 pnpm dedupe(또는 pnpm up next -r)로 잠금 파일을 정리해서 16.4.6 하나로 합쳐지는지 확인해 보는 방법도 있습니다. 이렇게 되면 루트에 영구 설정을 남기지 않아도 됩니다.
(근거: pnpm docs pnpm.overrides — "foo@<version": ... 형태로 대상 범위를 지정할 수 있음)
There was a problem hiding this comment.
c618459 에서 반영했습니다. (근거: pnpm docs pnpm.overrides)
두 방법을 모두 확인해 본 결과, 두 번째 방법(override 제거)으로 반영했습니다.
- selector(
"next@<16.4.6": "^16.4.6")로 바꾸면 앱을^17로 올릴 때 막히는 문제는 해결됩니다. 하지만@sentry/nextjs의 peer(^16.0.0-0)는 범위가<16.4.6과 겹쳐서 여전히next: ^16.4.6으로 덮어써졌습니다. - override를 제거하고
pnpm install만 실행하면 잠금 파일에next@16.4.6하나만 남습니다.@sentry/nextjspeer도 원래 범위(^13.2.0 || ^14.0 || ^15.0.0-rc.0 || ^16.0.0-0)로 돌아왔습니다. 잠금 파일 없이 새로 해석했을 때도 16.4.6 하나만 나옵니다. pnpm dedupe는kordoc의sharp등 관계없는 패키지까지 바꿔서 쓰지 않았습니다. 잠금 파일 변경은 7줄입니다.check-types,build,test,test:e2e모두 통과했습니다.
앱들의 직접 의존성 next: ^16.4.6이 보안 하한 역할을 하고, packages/api·packages/ui의 peer는 같은 인스턴스(16.4.6)로 해석됩니다.
개요 💡
pnpm audit --prod결과 프로덕션 의존성인next,axios,@sentry/nextjs에 치명(critical)·높음(high) 등급 보안 권고가 다수 있어, 패치된 버전으로 업데이트하였습니다.작업내용 ⌨️
nextapps/client,apps/admin@next/eslint-plugin-nextpackages/eslint-configaxiosapps/client,apps/admin,packages/api,packages/ui@sentry/nextjsapps/clientpackages/api,packages/ui의nextpeer(^16.0.0)가auto-install-peers로 자동 설치된 취약 버전next@16.2.10으로 남아 있었습니다. peer 범위나 루트pnpm.overrides로 하한을 강제하지 않고 잠금 파일만 다시 해석해,next@16.4.6하나로 통일하였습니다. peer 범위는 호환 범위인^16.0.0을 그대로 유지하며, 보안 하한은 앱의 직접 의존성(next: ^16.4.6)이 담당합니다. (리뷰 반영 과정은 각 스레드 참고)@sentry/nextjs는 메이저 업데이트(11.x)를 피하고, 패치 기준(10.75.2 이상)을 만족하는 10.x 최신 버전으로 올렸습니다.@sentry/nextjs10.78에서withSentryConfig를@sentry/nextjs에서 import하는 방식이 deprecated되어(v11에서 제거 예정),apps/client/next.config.mjs의 import 경로를@sentry/nextjs/config로 변경하였습니다.검증
pnpm audit --prod:next,axios,@sentry/nextjs관련 권고 0건 (critical 6건 → 1건)pnpm check-types,pnpm test,pnpm build,pnpm test:e2e(9건) 모두 통과하였습니다.pnpm lint는 에러 없이 통과하였습니다. 기존react-hooks/exhaustive-deps경고 8건은 이번 변경과 무관합니다.관련 이슈 🚨
리뷰 요청사항 👀
proxy-addr)과adm-zip,hono,markdown-it등 high 등급은 모두apps/ocr-lambda의kordoc하위 의존성입니다. 현재kordoc4.9.1에서 최신 4.24.65까지 버전 차이가 크고patches/kordoc.patch재적용 검토가 필요해, 이 PR에서는 다루지 않았습니다. 별도 작업으로 진행할 예정입니다.