[FIX] 디자인 시스템 절대 경로 별칭 문제 수정 - #95
Conversation
- tsconfig.json의 paths(@components, @lib, @tokens 등)가 타입 검사에만 적용되고 Next.js 번들러의 런타임 모듈 해석에는 영향을 주지 않아 timo-web 빌드가 깨지는 문제를 수정했습니다 - 컴포넌트 내부 import를 모두 상대 경로로 전환해 어떤 번들러에서도 별도 alias 설정 없이 정상 동작하도록 했습니다 - 더 이상 사용되지 않는 tsconfig.json의 paths 설정을 제거했습니다
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (29)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Timo Performance ReportBundle Size — timo-web
Lighthouse — timo-web
Image Optimization — timo-web
측정 커밋: |
3 participants
ISSUE 🔗
close #94
What is this PR? 🔍
디자인 시스템 패키지 내부에서 사용하던 절대 경로 별칭(
@components,@lib,@tokens등)이 timo-web(Next.js) 빌드에서 모듈 해석 실패를 일으키던 문제를 수정했습니다.배경
packages/timo-design-system의 컴포넌트들은 서로를@components/...,@lib같은 절대 경로 별칭으로 import했고, 이 별칭은 패키지 자체tsconfig.json의paths에만 정의되어 있었습니다. Storybook은.storybook/main.ts의viteFinal에서 동일한 별칭을 viteresolve.alias로 별도 재정의해두어 정상 동작했습니다.tsconfig.json의paths는 TypeScript 타입 검사와 IDE 인텔리센스에만 영향을 주며 실제 번들러의 런타임 모듈 해석에는 관여하지 않습니다.apps/timo-web/next.config.js는transpilePackages: ["@repo/timo-design-system"]로 이 패키지를 소스째로 트랜스파일하는데, Next.js 번들러가@components/...같은 지정자를 만나면.//로 시작하지 않으므로 일반 npm 패키지 이름으로 간주해node_modules에서 찾다가 실패합니다. Storybook의 alias 설정은 Storybook 자신에게만 적용되고 timo-web과는 공유되지 않기 때문에 이 문제가 드러나지 않고 있었습니다.tsconfig.json의paths를 제거했습니다. 어떤 번들러가 이 패키지를 소스째로 소비하더라도 별도 alias 설정 없이 동작하도록 했습니다.디자인 시스템 컴포넌트 import
packages/timo-design-system/src/components/index.ts를 포함한 15개 컴포넌트 파일의@components/...,@libimport를 전부 상대 경로(./,../)로 전환했습니다.paths와 Storybook의 vite alias에만 존재하고, timo-web의 Next.js 설정에는 대응하는 alias가 없어 빌드가 깨졌습니다.import { cn } from "@lib"``import { cn } from "../../lib"로 변경했습니다. Next.jsnext.config.js에 webpack/turbopack alias를 추가해 별칭을 유지하는 방법도 검토했으나, 이 패키지를 소비하는 모든 앱(현재 timo-web, 향후 추가될 앱 포함)마다 동일한 alias 설정을 중복해서 유지보수해야 하는 부담이 있어 채택하지 않았습니다.packages/timo-design-system/src/guides/StorybookGuide.mdx에 남아있는@tokens/color-tokenimport는 Storybook에서만 로드되는 문서용 파일이라 이번 PR 범위에서 제외했습니다.tsconfig.json
compilerOptions.paths(@components,@lib,@tokens,@icons,@styles,@assets,@guides)를 제거했습니다.To Reviewers
디자인 시스템 export/alias 문제와 관련해 별도로 확인된
packages/timo-design-system/package.json의exports["./styles"]가 실제 스타일이 있는globals.css가 아닌 빈components.css를 가리키는 문제는 이번 PR 범위에서 다루지 않았으며, 별도 이슈로 분리할 예정입니다. 이번 PR은 컴포넌트 간 import 해석 문제만 다룹니다.Screenshot 📷
Test Checklist ✔
pnpm turbo run check-types --filter=@repo/timo-design-system --filter=timo-web통과pnpm turbo run lint --filter=@repo/timo-design-system통과pnpm turbo run build --filter=timo-web통과 (수정 전 되돌려서Module not found에러로 실패하는 것도 재현 확인)