[Feat]: theme 패키지 생성

[minseong0324]

관련 이슈

close #35

변경 사항

theme 패키지를 ui 패키지와 따로 분리하여 관리하고자 했어요.

둘 간의 결합을 줄이고 싶었고, theme은 꼭 ui패키지 내 components에서만 사용되는 것이 아니기 때문에 패키지를 분리했습니다!

이 또한 esbuild를 활용했습니다.

레퍼런스

Summary by CodeRabbit

• 새로운 기능

  • 테마 패키지 추가
  • 다크 및 라이트 테마 구현
  • 색상, 간격, 타이포그래피, 테두리 반경 토큰 정의
  • Vanilla Extract를 사용한 CSS-in-JS 스타일링 지원

• 개선 사항

  • 일관된 디자인 시스템 구축
  • 재사용 가능한 스타일 유틸리티 생성

[coderabbitai]

Warning

There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure.

🔧 eslint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

packages/theme/esbuild.config.js

Oops! Something went wrong! :(

ESLint: 9.17.0

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@repo/eslint-config' imported from /eslint.config.mjs
at packageResolve (node:internal/modules/esm/resolve:839:9)
at moduleResolve (node:internal/modules/esm/resolve:908:18)
at defaultResolve (node:internal/modules/esm/resolve:1038:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:557:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:525:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:246:38)
at ModuleJob._link (node:internal/modules/esm/module_job:126:49)

Walkthrough

이 풀 리퀘스트는 새로운 테마 패키지를 생성하는 작업을 포함합니다. packages/theme 디렉토리에 새로운 패키지가 추가되었으며, Vanilla Extract를 사용하여 CSS-in-JS 스타일링 및 테마 관리를 위한 구성 요소들이 도입되었습니다. 패키지는 색상, 간격, 타이포그래피, 테마 토큰 등을 정의하고, 라이트 및 다크 테마를 지원합니다.

Changes

파일	변경 요약
packages/theme/esbuild.config.js	esbuild 빌드 구성 파일 추가
packages/theme/package.json	새 패키지 선언 및 스크립트 정의
packages/theme/src/index.ts	토큰, 테마, sprinkles 모듈 내보내기
packages/theme/src/sprinkles.css.ts	CSS 속성 및 단축키 정의
packages/theme/src/themes/*	테마 계약, 라이트/다크 테마 구현
packages/theme/src/tokens/*	색상, 간격, 반경, 타이포그래피 토큰 정의
packages/theme/tsconfig.json	TypeScript 구성 파일 추가

Assessment against linked issues

목표	해결 여부	설명
theme 패키지 분리	✅

Poem

🐰 토큰의 세계, 색과 공간의 춤
라이트와 다크, 테마의 꿈
바닐라 익스트랙트로 스타일 입혀
코드는 노래하고 디자인은 빛나네 🌈

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9883d11 and aa3b5a7.

📒 Files selected for processing (14)

• packages/theme/esbuild.config.js (1 hunks)
• packages/theme/package.json (1 hunks)
• packages/theme/src/index.ts (1 hunks)
• packages/theme/src/sprinkles.css.ts (1 hunks)
• packages/theme/src/themes/contract.ts (1 hunks)
• packages/theme/src/themes/dark.ts (1 hunks)
• packages/theme/src/themes/index.ts (1 hunks)
• packages/theme/src/themes/light.ts (1 hunks)
• packages/theme/src/tokens/colors.ts (1 hunks)
• packages/theme/src/tokens/index.ts (1 hunks)
• packages/theme/src/tokens/radius.ts (1 hunks)
• packages/theme/src/tokens/spacing.ts (1 hunks)
• packages/theme/src/tokens/typography.ts (1 hunks)
• packages/theme/tsconfig.json (1 hunks)

✅ Files skipped from review due to trivial changes (6)

• packages/theme/src/index.ts
• packages/theme/src/tokens/spacing.ts
• packages/theme/tsconfig.json
• packages/theme/src/tokens/typography.ts
• packages/theme/package.json
• packages/theme/src/tokens/radius.ts

🔇 Additional comments (25)

packages/theme/esbuild.config.js (2)

1-2: 필수 의존성 임포트 확인 완료
해당 라인에서 esbuild와 vanillaExtractPlugin을 임포트해 ES 빌드 작업과 Vanilla Extract 기반 스타일 처리를 안전하게 설정하고 있습니다. 문제 없어 보입니다.

---

4-4: watch 플래그 처리 적절
--watch 플래그를 통해 빌드 모드를 동적으로 제어하는 로직이 명확하며, 별도의 설정 없이도 유지보수하기 쉬워 보입니다.

packages/theme/src/tokens/index.ts (4)

1-4: 모듈 내보내기 구조가 명확합니다.
여러 토큰을 한꺼번에 내보냄으로써, 사용하는 쪽에서 편리하게 가져다 쓸 수 있어 보입니다. 추가적인 의존성을 줄이기 위해서라도 현재 구조를 유지하는 것이 좋아 보입니다.

---

6-9: 임포트 구문 확인
colors, radius, spacing, typography를 각각 명시적으로 불러와 토큰 오브젝트에 합치는 구조가 좋습니다. 이로 인해 각 토큰 간의 의도가 분명해집니다.

---

11-16: tokens 객체의 일관성
객체에 as const를 사용해 프로퍼티가 상수로 처리되어 안전성이 높아졌습니다. 디자인 토큰이 변경될 가능성이 낮다면, 불변으로 두어 오용을 방지하는 편이 유지보수에 유리합니다.

---

18-18: Tokens 타입 정의
typeof tokens를 이용해 객체 구조를 재활용하는 접근이 적절합니다. 다른 곳에서 Tokens 타입을 재사용하기 수월하겠네요.

packages/theme/src/themes/index.ts (3)

1-3: Vanilla Extract createTheme 함수 임포트
테마 설정을 위해 createTheme를 활용하는 접근이 훌륭합니다. 다양한 스킨 혹은 모드(라이트/다크 등)를 유연하게 관리하기에 적합합니다.

---

6-7: 라이트/다크 테마 생성 시도
createTheme<ThemeContract>(lightTheme)와 createTheme(vars, darkTheme)의 분리로 명확히 라이트/다크 테마를 구분할 수 있습니다. 이 구조는 향후 새로운 테마가 추가되더라도 확장하기 용이합니다.

---

9-11: 내보내기 구문 및 타입 재활용
lightThemeClass, darkThemeClass, vars를 함께 내보내어 외부에서 쉽게 사용할 수 있게 했으며, 타입 또한 명시적으로 노출하여 테마 소비 코드를 작성하기가 편리해집니다.

packages/theme/src/tokens/colors.ts (2)

1-2: colors 상수 선언
디자인 시스템에서 색상 팔레트 관리의 핵심이 되는 객체로 보입니다. export const colors로 내보내 재사용성을 높인 점이 적절합니다.

---

3-29: 다양한 색상 계층 관리
primary, semantic, grey로 색상을 구분해 가독성과 유지보수성을 높였습니다. 필요한 경우 추가 카테고리를 손쉽게 확장 가능하겠습니다.

packages/theme/src/sprinkles.css.ts (6)

1-3: Sprinkles 관련 유틸 임포트
@vanilla-extract/sprinkles에서 필요한 함수를 잘 가져오고 있고, vars를 병합해 스타일 시스템을 구성하는 구조가 좋습니다.

---

4-14: 색상 관련 프로퍼티 정의
color, background, borderColor에 관해 각각 vars.colors를 연결해주어 테마 배리에이션을 쉽게 적용할 수 있습니다. shorthand(bg, border)도 직관적입니다.

---

16-23: 공간 관련 프로퍼티 정의
padding, margin, gap, borderRadius에 대한 변수 연동이 깔끔합니다. 추후 spacing과 엣지 케이스를 확장하기도 용이해 보입니다.

---

25-31: 타이포그래피 관련 프로퍼티 정의
fontSize와 fontWeight 모두 토큰으로 관리되어 일관된 텍스트 스타일을 유지할 수 있습니다.

---

32-36: createSprinkles로 스프링클 조합
세 가지 프로퍼티 세트를 sprinkles에 합치면서 확장성을 확보하고 있습니다. 요구 사항에 따라 자유롭게 조합이 가능해 보입니다.

---

38-38: Sprinkles 타입 내보내기
함수 파라미터 타입을 재활용하여 타입 추론 및 오탈자 방지 효과가 큽니다. 다른 컴포넌트에서 안정적으로 적용될 것으로 보입니다.

packages/theme/src/themes/contract.ts (2)

35-49: spacing, radius, typography를 인덱스 시그니처로 연결한 점이 유용합니다.
tokens 구조 변화 시 자동 반영이 가능해 유지보수성에 용이합니다. 이대로 진행하셔도 좋을 것 같습니다.

---

3-34: 테마 컬러 타입 정의에 대한 구조적 접근이 매우 적절합니다.
해당 타입은 다양한 색상 변주 필요에 유연하게 대처할 수 있는 구조로 보입니다. 다만, grey50B와 같은 key가 토큰에서 올바르게 매핑되는지 한 번 더 확인을 권장드립니다.

packages/theme/src/themes/light.ts (3)

4-38: Light Theme 색상 매핑이 정확하고 의미가 잘 드러납니다.
전체적으로 tokens를 잘 활용하여 일관성 있는 테마 구성이 돋보입니다.

---

39-42: 이 부분은 재사용 관점에서 간결하고 효과적입니다.
tokens를 통째로 할당함으로써, 테마 속성 관리가 간편해집니다.

---

28-30: 이름과 실제 값 간의 불일치 가능성 확인이 필요합니다.
grey0to950, grey0to800, grey0to700이 모두 tokens.colors.grey[0]에 매핑되어 있는데, 다른 숫자 부분(950, 800, 700)은 실제로 사용되지 않아 네이밍과 값의 불일치가 우려됩니다.

✅ Verification successful

네이밍 규칙이 의도적인 디자인 시스템 패턴임을 확인했습니다

검증 결과, 이 네이밍은 라이트/다크 테마에서 일관된 패턴으로 사용되고 있습니다:

• dark.ts에서는 각각 grey[950], grey[800], grey[700] 값을 사용
• light.ts에서는 모두 grey[0] 값을 사용
• contract.ts에서 이러한 타입이 정의되어 있음

이는 테마별로 다른 값을 가지도록 설계된 의도적인 패턴으로 보입니다. 네이밍의 숫자는 다크 테마에서 사용되는 값을 기준으로 정해진 것으로 판단됩니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# grey0to950 등 키워드를 사용하는 부분을 전역 검색하여, 실제 의도대로 사용되는지 확인
rg -A 2 "grey0to(950|800|700)"

Length of output: 1101

packages/theme/src/themes/dark.ts (3)

4-38: Dark Theme 구성도 전반적으로 무난합니다.
색상 토큰이 적절히 매핑되어 있으며, 유지보수나 확장을 고려한 구조로 판단됩니다.

---

39-42: 전반적 구조가 일관되며, 테마 확장에도 유리합니다.
space, borderRadius, typography 등 공통 속성들을 그대로 재활용함으로써 향후 기능 추가에 대응하기 좋습니다.

---

7-7: primary400to200의 실제 값 확인이 필요합니다.
다크 테마에서 primary400to200 키가 green200에 할당되어 있는데, 기대한 400~200 범위와 일치하는지 점검해 보시길 권장드립니다.

✅ Verification successful

primary400to200 값이 테마별로 적절하게 설정되어 있습니다

검증 결과:

• 라이트 테마: green400 (#D2F634) 사용 - 가장 진한 색상 적용
• 다크 테마: green200 (#E6FF79) 사용 - 더 밝은 색상으로 적절히 대비
• 두 테마 모두 green100~400 범위 내에서 적절한 값을 선택하여 사용

색상값들이 테마의 특성에 맞게 잘 매핑되어 있으며, 네이밍 의도대로 400~200 범위 내의 값들이 사용되고 있습니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# 해당 키워드 실제 사용처를 검색하여 로직 상 일관되는지 확인
rg -A 2 "primary400to200"

Length of output: 636

---

Script:

#!/bin/bash
# tokens.colors.primary의 green 값들을 확인
rg -A 10 "green[0-9]+" packages/theme/src/tokens

Length of output: 819

[coderabbitai]

💡 Codebase verification

esbuild 설정이 올바르지 않습니다 - 수정이 필요합니다

package.json의 빌드 스크립트를 보면 format 옵션에 배열을 사용하는 것이 올바르지 않다는 것이 확인되었습니다. 현재 정상적으로 작동하는 빌드 스크립트는 ESM과 CJS 포맷에 대해 각각 별도의 esbuild 명령을 실행하고 있습니다:

"build": "tsc --emitDeclarationOnly && esbuild src/index.ts --bundle --platform=node --format=esm --outfile=dist/index.mjs && esbuild src/index.ts --bundle --platform=node --format=cjs --outfile=dist/index.js"

esbuild.config.js를 다음과 같이 수정해야 합니다:

Promise.all([
  build({
    entryPoints: ['src/index.ts'],
    bundle: true,
    platform: 'node',
    format: 'esm',
    outfile: 'dist/index.mjs',
    plugins: [vanillaExtractPlugin()],
    external: ['react'],
    watch: isWatch,
  }),
  build({
    entryPoints: ['src/index.ts'],
    bundle: true,
    platform: 'node',
    format: 'cjs',
    outfile: 'dist/index.js',
    plugins: [vanillaExtractPlugin()],
    external: ['react'],
    watch: isWatch,
  }),
]).catch(() => process.exit(1));

🔗 Analysis chain

format 옵션 유효성 검토 필요
format 속성에 배열(['esm', 'cjs'])을 전달하고 있는데, 기본적인 esbuild 설정에서 동시에 여러 가지 포맷을 지정하려면 각각의 포맷에 대해 별도 빌드 설정이 필요할 수 있습니다. 설정이 정상적으로 동작하는지 점검이 필요합니다.

아래 스크립트를 통해 esbuild 설정이 의도대로 작동하는지 확인해보세요:

정상적으로 빌드가 완료되지 않거나 에러가 발생한다면, 아래 예시와 같이 별도 빌드 과정을 분리하거나 하나의 포맷으로 지정하는 방식으로 수정해야 할 수 있습니다:

-build({
-  ...
-  format: ['esm', 'cjs'],
-  ...
-})
+Promise.all([
+  build({ ...commonOptions, format: 'esm', outdir: 'dist/esm' }),
+  build({ ...commonOptions, format: 'cjs', outdir: 'dist/cjs' }),
+]).catch(() => process.exit(1));

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# esbuild 설정 검사 스크립트
# 목적: esbuild가 ['esm', 'cjs'] 배열 형태로 format 옵션을 받아들일 수 있는지 점검

# 실제 빌드 실행
node packages/theme/esbuild.config.js --watch

Length of output: 1276

---

Script:

#!/bin/bash
# Check if esbuild is listed as a dependency in package.json
cat packages/theme/package.json

Length of output: 873

---

Script:

#!/bin/bash
# Check if there are any build output files in the dist directory
ls -la packages/theme/dist/

Length of output: 97

---

Script:

#!/bin/bash
# Search for any other esbuild configurations in the codebase
rg "format.*\[.*'(esm|cjs)'.*\]" -g "*.{js,ts,json}"

Length of output: 119

---

Script:

#!/bin/bash
# Look for build scripts in package.json that might use esbuild
rg "esbuild" packages/theme/package.json

Length of output: 435

[kongnayeon]

와 너무 깔끔해요~~ 고생 많으셨습니다 ㅎㅎ 저희 rem 변환해서 사용할지 px 그대로 사용할지만 논의해 보면 좋을 것 같아요!!