대규모 의존성 업그레이드를 단계적으로 수행하는 CLI 프롬프트
변수 입력4개
언제 사용하나
framework, runtime, ORM 등 핵심 의존성의 major version을 올리거나 여러 package를 함께 갱신해야 할 때 사용한다. lockfile만 바꾸는 작업이 아니라 migration guide, 호환성, 실행 환경을 함께 검증한다.
준비할 정보
{{TARGET}}: 업그레이드 대상과 현재·목표 버전{{SCOPE}}: 변경 가능한 package·application 범위{{VERIFY}}: lint, typecheck, test, build, smoke test 명령{{CONSTRAINTS}}: runtime, 배포, 하위 호환성 제약
복사해서 쓰는 CLI agent 프롬프트
{{TARGET}} 업그레이드를 검토하고 작은 단계로 수행해줘.
범위: {{SCOPE}}
검증: {{VERIFY}}
제약: {{CONSTRAINTS}}
1. 저장소 지침, 현재 working tree, package manager, lockfile, runtime 버전, monorepo 구조를 먼저 확인해.
2. 공식 release note·migration guide·security advisory를 확인하고 breaking change를 현재 사용 코드와 매핑해. 공식 근거가 없는 설정은 만들지 마.
3. 연관 업그레이드를 runtime/tooling, direct dependency, code migration, deprecated API 제거 단계로 나눠.
4. 각 단계가 독립적으로 build·review·revert 가능하게 commit 범위를 제안해.
5. 자동 codemod는 dry-run과 diff를 먼저 확인하고, 생성물·사용자 변경을 덮어쓰지 마.
6. dependency resolution 오류를 숨기기 위해 force, legacy peer dependency, 무조건 제외을 추가하지 마.
7. 각 단계 후 {{VERIFY}}를 실행하고 실패하면 다음 단계로 넘어가지 마.
8. lockfile·bundle size·image size·startup time·runtime warning의 변화를 보고해.
9. 배포나 외부 서비스 변경은 수행하지 말고 rollback 조건만 제안해.
결과: '버전·호환성 현황 / breaking change 매핑 / 단계별 계획 / 변경 diff / 검증 결과 / 성능·크기 변화 / 남은 위험 / rollback'중단 조건
목표 버전이 현재 runtime을 지원하지 않거나, 사용 중인 plugin의 호환 버전이 없거나, 복구 가능한 lockfile과 artifact가 없으면 작업을 멈춘다.
검수 방법
업그레이드 전후에 같은 명령과 smoke scenario를 사용한다. 새 warning·deprecated API·중복 package가 남았는지 확인하고, changelog에 사용자 영향과 rollback 방법을 남긴다.
댓글 0개
아직 댓글이 없습니다.