Setting(project): GitHub Actions CI (lint/build) 설정#13
Setting(project): GitHub Actions CI (lint/build) 설정#13constantly-dev merged 13 commits intodevelopfrom
Conversation
|
Warning Rate limit exceeded@constantly-dev has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 29 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
WalkthroughGitHub Actions CI 워크플로우 추가, 앱들에 디자인 시스템 CSS 임포트 추가, extension 앱에 ESLint 구성 및 패키지 변경, design-system에 ESM 타입·devDependencies 및 Vite 라이브러리 빌드 설정이 추가되었다. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as 개발자
participant GH as GitHub Actions
participant L as Job: lint
participant B as Job: build
Dev->>GH: Push / Pull Request (main, develop)
GH->>L: Start lint job
GH->>B: Start build job
par Lint job
L->>L: actions/checkout
L->>L: jq로 package.json.engines.node 추출 (outputs.version)
L->>L: actions/setup-node (outputs.version)
L->>L: pnpm/action-setup → pnpm install --frozen-lockfile
L->>L: pnpm run lint
and Build job
B->>B: actions/checkout
B->>B: jq로 package.json.engines.node 추출 (outputs.version)
B->>B: actions/setup-node (outputs.version)
B->>B: pnpm/action-setup → pnpm install --frozen-lockfile
B->>B: pnpm run build
end
sequenceDiagram
autonumber
participant Dev as 개발자
participant Vite as Vite (design-system)
participant Rollup as Rollup
participant Env as 소비자
Dev->>Vite: 빌드 요청 (library mode, entry: src/components/index.ts)
Vite->>Vite: 플러그인 적용 (React, Tailwind)
Vite->>Rollup: 번들링 (external: react, react-dom)
Rollup-->>Env: 출력 (design-system.{format}.js)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (7)
.github/workflows/ci.yml (7)
23-26: setup-node 캐시 활성화로 설치 속도 개선pnpm 사용 시 setup-node의 캐시 기능을 켜면 의존성 설치가 크게 빨라집니다.
다음 옵션을 추가해 주세요.
- uses: actions/setup-node@v4 with: - node-version: ${{ steps.get_node_version.outputs.version }} + node-version: ${{ steps.get_node_version.outputs.version }} + cache: pnpm + cache-dependency-path: pnpm-lock.yaml
27-31: pnpm 버전 고정 권장(재현성 향상)현재 pnpm/action-setup로 최신 버전이 설치될 수 있습니다. package.json의 packageManager(pnpm@x.y.z)에 맞추거나 Corepack을 써서 버전을 고정하는 것이 안전합니다.
아래 두 가지 중 하나를 선택해 적용해 주세요.
옵션 A: Corepack 사용(권장, Node 16.13+)
- - name: Setup Pnpm - uses: pnpm/action-setup@v4 + - name: Enable Corepack (use pnpm version from package.json "packageManager") + run: corepack enable옵션 B: pnpm/action-setup로 버전 고정
- name: Setup Pnpm - uses: pnpm/action-setup@v4 + uses: pnpm/action-setup@v4 + with: + version: 9 # repo에서 사용하는 메이저/정확한 버전으로 고정둘 중 무엇을 선택할지 명확하지 않다면 package.json에 "packageManager": "pnpm@<버전>"을 먼저 확인 바랍니다.
44-46: build 잡에도 pnpm 캐시 적용lint와 마찬가지로 빌드에서도 캐시를 켜 주세요.
- uses: actions/setup-node@v4 with: - node-version: ${{ steps.get_node_version.outputs.version }} + node-version: ${{ steps.get_node_version.outputs.version }} + cache: pnpm + cache-dependency-path: pnpm-lock.yaml
48-52: 의존성 설치는 한 번이면 충분합니다현 상태에서도 문제는 없지만, pnpm/action-setup에 run_install 옵션을 써 자동 설치하거나, Corepack 사용 시 별도 설정 없이 설치를 한 번만 실행해도 됩니다. 중복 설치는 없으나 빌드 시간 최적화 포인트입니다.
예: Corepack을 사용하고 단일 설치만 유지
- - run: pnpm install --frozen-lockfile - - run: pnpm run build + - run: pnpm install --frozen-lockfile + - run: pnpm run build또는 pnpm/action-setup 사용 시:
- - name: Setup Pnpm - uses: pnpm/action-setup@v4 + - name: Setup Pnpm + uses: pnpm/action-setup@v4 + with: + version: 9 + run_install: true - - run: pnpm install --frozen-lockfile
3-11: 트리거 범위 검토(옵션): 피처 브랜치 push에도 CI를 돌릴지 결정현재 push 트리거는 main/develop에 한정되어 있어 피처 브랜치에서는 PR 생성 전까지 CI가 동작하지 않습니다. 조기 피드백이 필요하다면 push에 모든 브랜치를 포함하고, pull_request는 지금처럼 보호 브랜치로 제한하는 구성도 고려할 수 있습니다.
예시:
on: push: branches: - - main - - develop + - '**' pull_request: branches: - main - develop팀 정책에 따라 유지해도 무방합니다.
1-13: 토큰 권한 최소화와 중복 실행 방지(옵션)보안과 비용 최적화를 위해 permissions 최소화와 concurrency를 추가하는 것을 권장합니다.
name: ci + +permissions: + contents: read + +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true
13-35: 전반적인 구성은 명확하고 충분히 작동 가능해 보입니다체크아웃 → Node/pnpm 설정 → 설치 → lint 순서가 명확하고, 빌드 잡도 동일한 패턴으로 구성되어 있습니다. 위 보완사항만 반영되면 안정성과 속도가 더욱 개선될 것입니다.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/ci.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#2
File: pnpm-workspace.yaml:3-3
Timestamp: 2025-08-18T13:48:59.021Z
Learning: constantly-dev는 docs 디렉터리를 컨벤션 문서 추가용으로 사용할 예정이라고 명시했습니다.
| - name: Extract Node.js version from package.json | ||
| id: get_node_version | ||
| run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT | ||
|
|
||
| - uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: ${{ steps.get_node_version.outputs.version }} | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
엔진 필드(engines.node)가 범위(>=, ^, ~ 등)일 때 setup-node가 실패할 수 있습니다
package.json의 engines.node가 범위 표현이면 actions/setup-node가 버전을 해석하지 못해 잡이 바로 실패합니다. .nvmrc가 있으면 우선 사용하고, 없거나 범위면 lts/*로 폴백하도록 보강하는 편이 안전합니다.
다음과 같이 step 스크립트를 보강해 주세요.
- - name: Extract Node.js version from package.json
- id: get_node_version
- run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT
+ - name: Extract Node.js version (prefer .nvmrc, fallback to engines.node or lts/*)
+ id: get_node_version
+ run: |
+ version=""
+ if [ -f .nvmrc ]; then
+ version="$(cat .nvmrc)"
+ else
+ version="$(jq -r '.engines.node // empty' package.json)"
+ fi
+ if [ -z "$version" ] || [[ "$version" =~ [><=\^~] ]]; then
+ version="lts/*"
+ fi
+ echo "version=$version" >> "$GITHUB_OUTPUT"추가로 setup-node가 같은 값을 사용합니다(아래 캐시 제안과 함께 반영 권장).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Extract Node.js version from package.json | |
| id: get_node_version | |
| run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT | |
| - uses: actions/setup-node@v4 | |
| with: | |
| node-version: ${{ steps.get_node_version.outputs.version }} | |
| - name: Extract Node.js version (prefer .nvmrc, fallback to engines.node or lts/*) | |
| id: get_node_version | |
| run: | | |
| version="" | |
| if [ -f .nvmrc ]; then | |
| version="$(cat .nvmrc)" | |
| else | |
| version="$(jq -r '.engines.node // empty' package.json)" | |
| fi | |
| if [ -z "$version" ] || [[ "$version" =~ [><=\^~] ]]; then | |
| version="lts/*" | |
| fi | |
| echo "version=$version" >> "$GITHUB_OUTPUT" |
🤖 Prompt for AI Agents
.github/workflows/ci.yml lines 19-26: the workflow extracts engines.node
directly which can be a semver range and break actions/setup-node; modify the
step to first prefer .nvmrc if present, otherwise read package.json.engines.node
and if that value contains range characters (^ ~ > = * x or a range) fall back
to "lts/*", then echo that chosen resolved version into GITHUB_OUTPUT (version)
and ensure the subsequent actions/setup-node step uses that same output value;
implement the range-detection and fallback logic in the run script so setup-node
receives a concrete usable version.
| - name: Extract Node.js version from package.json | ||
| id: get_node_version | ||
| run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT | ||
|
|
||
| - uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: ${{ steps.get_node_version.outputs.version }} | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
build 잡도 Node 버전 추출 로직 동일 이슈
lint 잡과 동일하게 build 잡에서도 engines.node가 범위면 실패할 수 있습니다. 동일한 폴백 로직을 적용해 주세요.
- - name: Extract Node.js version from package.json
- id: get_node_version
- run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT
+ - name: Extract Node.js version (prefer .nvmrc, fallback to engines.node or lts/*)
+ id: get_node_version
+ run: |
+ version=""
+ if [ -f .nvmrc ]; then
+ version="$(cat .nvmrc)"
+ else
+ version="$(jq -r '.engines.node // empty' package.json)"
+ fi
+ if [ -z "$version" ] || [[ "$version" =~ [><=\^~] ]]; then
+ version="lts/*"
+ fi
+ echo "version=$version" >> "$GITHUB_OUTPUT"그리고 setup-node에도 캐시 옵션을 함께 추가하는 것을 권장합니다(아래 diff).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Extract Node.js version from package.json | |
| id: get_node_version | |
| run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT | |
| - uses: actions/setup-node@v4 | |
| with: | |
| node-version: ${{ steps.get_node_version.outputs.version }} | |
| - name: Extract Node.js version (prefer .nvmrc, fallback to engines.node or lts/*) | |
| id: get_node_version | |
| run: | | |
| version="" | |
| if [ -f .nvmrc ]; then | |
| version="$(cat .nvmrc)" | |
| else | |
| version="$(jq -r '.engines.node // empty' package.json)" | |
| fi | |
| if [ -z "$version" ] || [[ "$version" =~ [><=\^~] ]]; then | |
| version="lts/*" | |
| fi | |
| echo "version=$version" >> "$GITHUB_OUTPUT" | |
| - uses: actions/setup-node@v4 | |
| with: | |
| node-version: ${{ steps.get_node_version.outputs.version }} |
🤖 Prompt for AI Agents
.github/workflows/ci.yml lines 40-47: the build job extracts engines.node
directly which can be a semver range and fail like the lint job; update the
extraction step to use the same fallback logic as lint (parse engines.node to a
concrete major/minor/patch when possible and if it’s a range or missing, fall
back to a defined default such as 'lts/*' or a repo-default version), and then
pass that resolved value to actions/setup-node; also add the setup-node cache
option (e.g., cache: 'npm' or 'yarn' depending on the project) to enable
dependency caching.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
packages/design-system/package.json (1)
30-32: TS/TS-ESLint 버전 정합성 정리 권장현재 워크스페이스 내 TypeScript(여기 5.9.2) 및 typescript-eslint(여기 ^8.39.1) 버전이 앱별로 상이합니다. ESLint v9 조합에서 버전 드리프트는 플러그인 peer-deps 경고 및 규칙 동작 차이를 유발할 수 있습니다. 루트에서 overrides로 통일하거나 workspace:*로 정렬을 고려해 주세요.
워크스페이스 전체 통일 예시는 다음과 같습니다(루트 package.json에 추가):
{ "pnpm": { "overrides": { "typescript": "5.9.2", "typescript-eslint": "^8.39.1", "eslint": "^9.33.0" } } }또한, 디자인 시스템은 라이브러리 성격이므로 React/ReactDOM를 peerDependencies로 노출하고 devDependencies에만 자체 개발용으로 두는 구성이 일반적입니다. 이렇게 해야 소비자 앱과 리액트 인스턴스가 중복되지 않습니다. 예시:
{ "peerDependencies": { "react": "^18 || ^19", "react-dom": "^18 || ^19" }, "devDependencies": { "react": "^19.1.0", "react-dom": "^19.1.0" }, "dependencies": { // 여기에서는 react, react-dom 제거 } }apps/extension/package.json (1)
20-25: @pinback/design-system는 런타임 의존성 — devDependencies 대신 dependencies에 두는 것을 권장애플리케이션이 디자인 시스템 컴포넌트를 런타임에 사용한다면 일반적으로 dependencies에 선언합니다. devDependencies에 두어도 번들에는 포함되지만 의도 표현과 배포 환경 일관성 측면에서 dependencies가 더 명확합니다. 또한
@vitejs/plugin-react와@vitejs/plugin-react-swc가 동시에 설치되어 있는데, 실제 Vite 설정에서 둘 중 하나만 사용한다면 중복 의존성은 정리하는 편이 좋습니다.가능한 정리 예시(요지):
- Vite 설정에서 사용하는 플러그인만 남기기
- 디자인 시스템을 dependencies로 이동
{ "dependencies": { "@pinback/design-system": "workspace:*" }, "devDependencies": { // "@pinback/design-system": 항목 제거 // "@vitejs/plugin-react" 또는 "@vitejs/plugin-react-swc" 중 실제로 쓰는 것만 유지 } }packages/design-system/vite.config.ts (2)
1-3: 선택: node:path 네임스페이스 사용으로 의도 명확화Node 내장 모듈은
node:프리픽스를 사용하는 것이 권장됩니다. 또한 default import 대신 네임스페이스 import가 더 일반적입니다.예시:
-import path from 'path'; +import * as path from 'node:path';
15-29: 선택: 라이브러리 배포 시 타입/포맷 보강 제안디자인 시스템 배포가 목적이라면 타입 선언 배출과 빌드 포맷 명시를 고려해 주세요. 예를 들어
vite-plugin-dts로 d.ts를 생성하고formats: ['es', 'cjs']를 지정하면 소비자 환경 호환성이 좋아집니다.원하시면
vite-plugin-dts포함한 설정 패치와 package.json의 exports 정리(PR 보강용)까지 제안 드리겠습니다.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
apps/extension/eslint.config.js(1 hunks)apps/extension/package.json(2 hunks)packages/design-system/eslint.config.mjs(1 hunks)packages/design-system/package.json(2 hunks)packages/design-system/vite.config.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#2
File: pnpm-workspace.yaml:3-3
Timestamp: 2025-08-18T13:48:59.021Z
Learning: constantly-dev는 docs 디렉터리를 컨벤션 문서 추가용으로 사용할 예정이라고 명시했습니다.
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This is used with the tailwindcss/vite plugin.
Applied to files:
packages/design-system/vite.config.tspackages/design-system/package.json
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This single import pulls in all of Tailwind's preflight, components, and utilities in one step and is used with the tailwindcss/vite plugin.
Applied to files:
packages/design-system/vite.config.tspackages/design-system/package.json
🔇 Additional comments (3)
packages/design-system/eslint.config.mjs (1)
1-4: LGTM — default import 전환 및 ESM 일관성 좋습니다내부 공유 ESLint 설정을 default import로 통일한 점과 JSDoc 타입 주석 모두 적절합니다. CI의 lint 단계에서 문제 없이 동작할 것으로 보입니다.
apps/extension/eslint.config.js (1)
1-5: 불필요한 교체 제안: reactRefresh.configs.vite 사용 가능
eslint-plugin-react-refresh 0.4.x 릴리스군에서 Flat Config용configs.vite프리셋이 공식으로 제공되므로, 기존 코드(...config, reactRefresh.configs.vite)를 그대로 유지해도 안전합니다.packages/design-system/package.json (1)
4-4: ESM 전환(type: "module") 적용 확인패키지의 ESM 전환은 모노레포 최신 툴링과 맞습니다. 다만 ESM 환경에서는
__dirname이 기본 제공되지 않으므로, 동일 PR에서 추가된 Vite 설정 파일에서 이를 보완해야 합니다(아래 vite.config.ts 코멘트 참조).
| '@': path.resolve(__dirname, 'src'), | ||
| '@utils': path.resolve(__dirname, './src/utils'), |
There was a problem hiding this comment.
ESM에서 __dirname은 정의되지 않음 — Vite 실행 시 ReferenceError
현재 파일은 ESM(패키지 type: module)인데 __dirname을 직접 사용하고 있습니다. Node ESM에서는 __dirname이 제공되지 않아 설정 평가 시 즉시 실패합니다. 아래처럼 fileURLToPath로 대체해 주세요.
적용 제안:
import tailwindcss from '@tailwindcss/vite';
import react from '@vitejs/plugin-react';
import path from 'path';
+import { fileURLToPath } from 'node:url';
import { defineConfig } from 'vite';
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
export default defineConfig({
plugins: [react(), tailwindcss()],
resolve: {
alias: {
'@': path.resolve(__dirname, 'src'),
'@utils': path.resolve(__dirname, './src/utils'),
},
},🤖 Prompt for AI Agents
In packages/design-system/vite.config.ts around lines 10 to 11, the config is
using the Node CommonJS global __dirname which is undefined in ESM and causes a
ReferenceError when Vite evaluates the file; replace direct __dirname usage by
importing fileURLToPath and dirname from 'url' and 'path' respectively (or use
only fileURLToPath + path.dirname) to compute a localDir variable from
import.meta.url, then use that localDir in path.resolve calls for '@' and
'@utils' so the aliases are built from a proper filesystem path in ESM.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/design-system/package.json (1)
34-41: React/ReactDOM는 peerDependencies로 이동 권장 — 중복 React 인스턴스 위험 방지라이브러리 성격의 패키지에서 react, react-dom를 dependencies에 두면 소비자 앱과 중복 설치/번들이 발생해 Hook 에러 등 치명적 문제가 유발될 수 있습니다. peerDependencies로 선언하고 devDependencies에 개발용으로만 추가하는 패턴을 권장합니다.
아래와 같이 변경을 제안드립니다:
"dependencies": { "@radix-ui/react-slot": "^1.2.3", "class-variance-authority": "^0.7.1", "clsx": "^2.1.1", - "lucide-react": "^0.540.0", - "react": "^19.1.0", - "react-dom": "^19.1.0", + "lucide-react": "^0.540.0", "tailwind-merge": "^3.3.1", "tw-animate-css": "^1.3.7" }, + "peerDependencies": { + "react": "^19", + "react-dom": "^19" + }, + "devDependencies": { + // ... 기존 devDependencies 유지 + "react": "^19.1.0", + "react-dom": "^19.1.0" + }원하시면 워크스페이스 전반에서 react/react-dom를 peer로 일관화되어 있는지 점검하는 스크립트도 제공하겠습니다.
🧹 Nitpick comments (5)
apps/extension/package.json (1)
20-25: ESLint 도구 체인 업데이트 확인 완료
eslint-plugin-react-hooks(v^5.2.0)는@pinback/eslint-config/react-internal에서 이미 활성화되어 있어,apps/extension/package.json에도 중복 선언되어 있습니다. 문제는 없으나 불필요할 수 있습니다.eslint-plugin-react-refresh(v^0.4.20)는eslint.config.js에서reactRefresh.configs.vite로 명확히 사용 중입니다.- 워크스페이스 내 모든
package.json에서eslint-plugin-react-hooks와eslint-plugin-react-refresh의 메이저 버전이 일관되게 v5.x/ v0.x로 유지되고 있습니다.- 루트
pnpm.overrides에는vite: "7.1.2"만 정의되어 있으며, ESLint 관련 오버라이드는 없습니다.apps/extension/eslint.config.js (1)
1-5: Flat Config 구성 적절 — Vite용 react-refresh 룰 합치기 OKbase config 뒤에 reactRefresh.configs.vite를 붙이는 구조가 맞고, ESM(import/export)도 package.json의 type: module과 호환됩니다. 운영에 문제 없어 보입니다.
옵션: 워크스페이스 전반의 일관성을 위해 이 파일도 .mjs 확장자로 통일하는 방안을 고려해 볼 수 있습니다(현 상태도 정상 동작).
packages/design-system/package.json (1)
6-11: exports가 TS 소스 경로를 가리키고 있습니다 — 장기적으로는 dist 산출물로 노출 고려 권장현재 "./ui", "./icons", "./utils"가 src/*.ts를 직접 가리킵니다. 모노레포 내부 Vite 앱에서는 동작하지만, 패키지를 외부에서 재사용하거나 타입 배포/빌드 시간을 최적화하려면 dist 산출물(JS, d.ts)을 노출하도록 재구성하는 것이 좋습니다. 즉 main/module/types(또는 exports 조건부)로 dist 경로를 지정하는 구조로 확장하는 방향을 검토해 주세요.
packages/design-system/vite.config.ts (2)
14-19: 형식(formats) 최소화와 소스맵 옵션은 선택적으로 고려내부 소비 목적이라면 ES 포맷 단일 산출물이 단순합니다. 디버깅 편의를 위해 sourcemap도 켜는 것을 권장합니다.
build: { lib: { entry: 'src/components/index.ts', name: 'DesignSystem', fileName: (format) => `design-system.${format}.js`, }, + sourcemap: true, + formats: ['es'], rollupOptions: {
9-12: 별칭 명명 혼동 가능성(@utils vs ./src/lib export)package.json의 exports에는 "./utils"가 ./src/lib/index.ts를 가리키는 반면, Vite 별칭 '@utils'는 ./src/utils를 가리킵니다. 개발자 혼란을 줄이려면 명칭을 일치시키거나 '@lib' 등으로 변경하는 것을 권장합니다.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
apps/client/src/App.css(1 hunks)apps/extension/eslint.config.js(1 hunks)apps/extension/package.json(2 hunks)apps/extension/src/App.css(1 hunks)apps/extension/src/index.css(0 hunks)apps/landing/src/App.css(1 hunks)packages/design-system/eslint.config.mjs(1 hunks)packages/design-system/package.json(2 hunks)packages/design-system/vite.config.ts(1 hunks)
💤 Files with no reviewable changes (1)
- apps/extension/src/index.css
✅ Files skipped from review due to trivial changes (1)
- apps/extension/src/App.css
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#2
File: pnpm-workspace.yaml:3-3
Timestamp: 2025-08-18T13:48:59.021Z
Learning: constantly-dev는 docs 디렉터리를 컨벤션 문서 추가용으로 사용할 예정이라고 명시했습니다.
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This is used with the tailwindcss/vite plugin.
Applied to files:
packages/design-system/vite.config.tsapps/landing/src/App.csspackages/design-system/package.jsonapps/client/src/App.css
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This single import pulls in all of Tailwind's preflight, components, and utilities in one step and is used with the tailwindcss/vite plugin.
Applied to files:
packages/design-system/vite.config.tsapps/landing/src/App.csspackages/design-system/package.jsonapps/client/src/App.css
📚 Learning: 2025-08-19T17:18:57.657Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#5
File: apps/extension/src/index.css:1-1
Timestamp: 2025-08-19T17:18:57.657Z
Learning: constantly-dev는 디자인 시스템 설정 PR 머지 후 `import 'pinback/tailwind-config/shared-styles.css';`를 `app.css`나 `index.css`에서 사용하여 공유 스타일을 관리할 계획입니다.
Applied to files:
apps/landing/src/App.cssapps/client/src/App.css
🔇 Additional comments (4)
apps/landing/src/App.css (1)
2-2: Landing에도 동일한 임포트 적용 LGTM앱 간 스타일 소스 일관성 확보 측면에서 좋습니다. 위 client 코멘트의 경합/중복 체크만 함께 확인해 주세요.
packages/design-system/eslint.config.mjs (1)
1-1: default import 적용 적합 확인패키지
@pinback/eslint-config/react-internal이config변수를 default export 하고 있으며, 이config는 배열로 정의되어 있습니다. 또한apps/extension,apps/client,apps/landing,packages/design-system등 모든 소비처에서 이미 default import를 일관되게 사용 중이므로, 이번 변경으로 인한 문제는 없습니다.packages/design-system/package.json (2)
4-4: ESM 전환(type: "module") 자체는 OK, 다만 vite.config.ts의 __dirname 사용과 충돌합니다패키지를 ESM으로 전환하면 Node ESM 스코프에서는 __dirname이 정의되지 않습니다. 현재 vite.config.ts에서 __dirname을 사용하고 있어 런타임 에러가 발생할 수 있습니다. vite 설정에서 fileURLToPath(new URL(..., import.meta.url)) 방식으로 교체가 필요합니다. 해당 파일 코멘트에 수정 제안을 남겼습니다.
9-9: styles 엔트리 파일 존재 확인 완료
packages/design-system/styles.css파일이 실제로 존재합니다.apps/extension,apps/landing,apps/client3개 앱에서 각각
@pinback/design-system/styles.css를 정상적으로 import 하고 있는 것이 확인되었습니다.따라서
exports의"./styles": "./styles.css"설정은 의도한 대로 동작하며, 추가 조치가 필요 없습니다.
apps/client/src/App.css
Outdated
| @@ -1 +1,2 @@ | |||
| @import '@pinback/tailwind-config/shared-styles.css'; | |||
| @import '@pinback/design-system/styles.css'; | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
디자인 시스템 CSS 임포트 추가 LGTM — 경합/중복만 확인해 주세요
공유 스타일 다음에 design-system 스타일을 가져오는 순서 선택은 합리적입니다. 다만 아래 2가지만 확인 부탁드립니다:
- @pinback/design-system 패키지가 styles.css를 exports에 노출하고 있는지(번들러/CI에서 경로 해석 실패 방지).
- shared-styles.css가 Tailwind 프리플라이트/토큰을 이미 포함한다면 design-system/styles.css에 동일 내용이 중복되지 않는지(중복 reset/규칙으로 인한 스타일 뒤엉킴 방지).
다음 스크립트로 노출 및 사용 현황을 빠르게 점검할 수 있습니다:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "1) 각 앱에서 design-system/styles.css 임포트 확인"
rg -nP --type=css -C0 "@import\\s+['\"]@pinback/design-system/styles\\.css['\"]"
echo
echo "2) design-system 패키지에서 styles.css export/파일 존재 확인"
if [ -f packages/design-system/package.json ]; then
echo "- exports['./styles.css'] 존재 여부"
jq -r '.exports?["./styles.css"] // "MISSING"' packages/design-system/package.json
echo "- files 배열에 styles.css 포함 여부(있다면 출력)"
jq -r '.files? // [] | map(select(test("styles\\.css"))) | .[]?' packages/design-system/package.json
echo "- 실제 파일 존재 위치 탐색"
fd -a -t f 'styles.css' packages/design-system || true
else
echo "packages/design-system/package.json 파일을 찾을 수 없습니다."
fiLength of output: 1079
design-system/styles.css 패키지 노출 및 중복 확인 필요
다음 사항을 처리해주세요:
-
package.json exports 누락
packages/design-system/styles.css파일은 실제로 존재하나, package.json의exports["./styles.css"]에 미등록(MISSING)되어 있어 번들러/CI에서 경로 해석 실패 또는 npm publish 시 미포함될 수 있습니다.package.json에 아래와 같이 exports 또는files항목에styles.css를 추가해주세요.// 예시: package.json { "exports": { "./styles.css": "./styles.css", … }, "files": [ "styles.css", … ] }
-
shared-styles.css 중복 여부
- Tailwind 프리플라이트/토큰이
shared-styles.css에 이미 포함되어 있다면,@pinback/design-system/styles.css에 동일 reset/규칙이 중복되지 않는지 확인해주세요. - 중복된 스타일 정의가 있을 경우 둘 중 한 쪽에서만 관리하도록 조정하여 스타일 충돌을 예방해야 합니다.
- Tailwind 프리플라이트/토큰이
🤖 Prompt for AI Agents
In apps/client/src/App.css around line 2, the import of
@pinback/design-system/styles.css will fail if the design-system package doesn't
export styles.css and may also cause duplicate resets with shared-styles.css;
update the design-system package.json to include an exports entry for
"./styles.css" (or add styles.css to the "files" array) so the file is
resolvable and published, then inspect shared-styles.css and styles.css for
overlapping Tailwind preflight/token/reset rules and remove or consolidate
duplicated rules so only one module provides the global resets.
packages/design-system/package.json
Outdated
| "@tailwindcss/vite": "^4.1.11", | ||
| "@vitejs/plugin-react": "^4.5.2", | ||
| "@turbo/gen": "^2.5.0", | ||
| "@types/node": "^22.15.3", | ||
| "@types/react": "19.1.0", | ||
| "@types/react-dom": "19.1.1", | ||
| "eslint": "^9.33.0", | ||
| "tailwindcss": "^4.1.12", | ||
| "typescript": "5.9.2" | ||
| "typescript": "5.9.2", | ||
| "typescript-eslint": "^8.39.1", | ||
| "vite": "^7.1.2" | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Vite/Tailwind/ESLint 도구 체인 추가는 방향성 좋습니다
@tailwindcss/vite, @vitejs/plugin-react, typescript-eslint, vite 추가로 빌드/린트 파이프라인 구성에 필요한 준비가 잘 되어 있습니다. 워크스페이스 전체에서 vite/플러그인 버전이 일관적인지만 한 번 확인 부탁드립니다.
다음 스크립트로 워크스페이스 내 Vite/플러그인 버전 불일치 여부를 빠르게 훑어볼 수 있습니다:
🏁 Script executed:
#!/bin/bash
echo "== Vite versions =="
fd -a package.json | xargs -I{} jq -r '[input_filename, (.devDependencies.vite // .dependencies.vite // empty)] | @tsv' {} | awk 'NF>1'
echo
echo "== @vitejs/plugin-react versions =="
fd -a package.json | xargs -I{} jq -r '[input_filename, (.devDependencies["@vitejs/plugin-react"] // empty)] | @tsv' {} | awk 'NF>1'
echo
echo "== @tailwindcss/vite versions =="
fd -a package.json | xargs -I{} jq -r '[input_filename, (.devDependencies["@tailwindcss/vite"] // .dependencies["@tailwindcss/vite"] // empty)] | @tsv' {} | awk 'NF>1'Length of output: 1271
워크스페이스 플러그인 버전 일관성 확인 결과
– vite
• packages/design-system/package.json: ^7.1.2
• apps/client, apps/extension, apps/landing: ^7.1.2
• 루트 package.json: 7.1.2 (필요 시 ^7.1.2로 통일 고려)
– @vitejs/plugin-react
• packages/design-system/package.json: ^4.5.2
• apps/extension/package.json: ^4.3.1
→ 동일한 버전으로 맞춰주세요.
– @tailwindcss/vite
• packages/design-system/package.json: ^4.1.11
• apps/client, apps/extension, apps/landing: ^4.1.12
→ design-system 쪽을 ^4.1.12로 올려주세요.
위치
• packages/design-system/package.json (plugin-react, tailwindcss)
• apps/extension/package.json (@vitejs/plugin-react)
전체 워크스페이스의 버전 스펙(캐럿 사용 여부 포함)도 한 번 더 검토하시면 좋겠습니다.
🤖 Prompt for AI Agents
packages/design-system/package.json lines 22-33: update plugin versions to match
the workspace — change "@tailwindcss/vite" to "^4.1.12" and
"@vitejs/plugin-react" to "^4.3.1" (to match apps/extension), then re-run
install; also review and normalize caret usage for "vite" and other plugins
across root and apps (e.g., use "^7.1.2" consistently) so workspace versions are
consistent.
| '@': path.resolve(__dirname, 'src'), | ||
| '@utils': path.resolve(__dirname, './src/utils'), | ||
| }, |
There was a problem hiding this comment.
ESM 환경에서 __dirname 미정의로 인한 런타임 에러 발생 — fileURLToPath로 교체 필요
package.json에 "type": "module"이 설정되어 있어 이 설정 파일은 ESM으로 해석됩니다. ESM 스코프에서는 __dirname이 정의되지 않으므로 현재 alias 설정에서 런타임 에러가 발생합니다.
아래와 같이 수정해 주세요:
-import path from 'path';
+import { fileURLToPath, URL } from 'node:url';
export default defineConfig({
plugins: [react(), tailwindcss()],
resolve: {
alias: {
- '@': path.resolve(__dirname, 'src'),
- '@utils': path.resolve(__dirname, './src/utils'),
+ '@': fileURLToPath(new URL('./src', import.meta.url)),
+ '@utils': fileURLToPath(new URL('./src/utils', import.meta.url)),
},
},검증 스크립트:
#!/bin/bash
# __dirname 사용 여부 점검
rg -n "__dirname\b" packages/design-system/vite.config.ts || echo "OK: __dirname not used"🤖 Prompt for AI Agents
packages/design-system/vite.config.ts around lines 10 to 12: the config
currently uses __dirname which is undefined in ESM and causes runtime errors;
replace __dirname usage with a dirname computed from
fileURLToPath(import.meta.url) (import { fileURLToPath } from 'url' and use
path.dirname) and update the alias targets to use that dirname (e.g., const
__filename = fileURLToPath(import.meta.url); const __dirname =
path.dirname(__filename); then use path.resolve(__dirname, 'src') etc.) so the
aliases work in ESM.
| rollupOptions: { | ||
| external: ['react', 'react-dom'], | ||
| output: { | ||
| globals: { | ||
| react: 'React', | ||
| 'react-dom': 'ReactDOM', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
react/jsx-runtime도 external로 지정 권장
ESM/라이브러리 빌드에서 JSX 런타임이 번들에 끌려 들어오는 것을 방지하려면 'react/jsx-runtime'를 함께 external 처리하는 것이 안전합니다.
rollupOptions: {
- external: ['react', 'react-dom'],
+ external: ['react', 'react-dom', 'react/jsx-runtime'],
output: {
globals: {
react: 'React',
'react-dom': 'ReactDOM',
},
},
},🤖 Prompt for AI Agents
In packages/design-system/vite.config.ts around lines 20 to 27, the
rollupOptions.external list is missing 'react/jsx-runtime', which can cause the
JSX runtime to be bundled into library builds; add 'react/jsx-runtime' to the
external array and also add a corresponding entry to output.globals (e.g.,
'react/jsx-runtime': 'jsxRuntime' or an appropriate global name) so the runtime
stays external in ESM/UMD builds and avoids being inlined into the bundle.
jjangminii
left a comment
jjangminii
left a comment
There was a problem hiding this comment.
고생하셨습니다-!! CI 설정하면서 다른 파일들 추가 설정한거같은데 제가 맞게 생각했는지 확인해주세요 ㅎㅎ
apps/extension/package.json
Outdated
| "@pinback/eslint-config": "workspace:*", | ||
| "@pinback/typescript-config": "workspace:*", | ||
| "@pinback/tailwind-config": "workspace:*", | ||
| "@pinback/design-system": "workspace:*", |
There was a problem hiding this comment.
이 부분은 다른 apps내의 파일들과 같은 세팅같은데 지금 추가된게 맞을까요?
There was a problem hiding this comment.
맞아요! extension에서도 공통 config 의존이 필요해서 workspace:* 추가해줬어요.
apps/extension/package.json
Outdated
| @@ -25,10 +30,11 @@ | |||
| "@vitejs/plugin-react": "^4.3.1", | |||
There was a problem hiding this comment.
저희 이거 없어도되지않나요?? 더이상 babel 사용하지 않는걸로 알고있어서 밑의 플러그인과 중복되는거 같아요
There was a problem hiding this comment.
그렇네요! 지우겠습니다 감사합니다 👍
jllee000
left a comment
jllee000
left a comment
There was a problem hiding this comment.
고생하셨습니다! 코드 보다가 개념(?)적인 개인 질문이 있었습니당 확인 부탁드려요 :)
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - name: Extract Node.js version from package.json | ||
| id: get_node_version | ||
| run: echo "version=$(jq -r '.engines.node' package.json)" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
just 질문 사항인디! 이거 Node.js 키워드가 있는데, 혹시 이거는 어떤 것 때문에 쓰는 걸까요!
There was a problem hiding this comment.
패키지 매니저: npm, yarn, pnpm
린터(Linter): ESLint
번들러/빌드 도구: Vite, Webpack, TypeScript 컴파일러(tsc)
해당 도구들이 모두 Node.js 환경에서 실행되는 프로그램이기 때문입니다!
| "typescript": "5.9.2", | ||
| "typescript-eslint": "^8.39.1", | ||
| "vite": "^7.1.2" |
There was a problem hiding this comment.
이것도 질문인데
-
제일 루트 쪽 package.json에 vite등등 버전 세팅이 있는데 이게 자동 연동되는 게 아니라, 디자인 시스템 package.json에서도 직접 세팅 또 해줘야하는건가요?
-
그리고 이 코드가 이제 추가가 되게된 이슈가 있었나용? 뭐 빌드에러가 있었던가의 이슈?
There was a problem hiding this comment.
- 맞아요! 사실 의존성은 필요한 곳에서 다 추가를 해줘야 해요. 패키지에서 필요한 의존을 다 따로 추가해줬어요. 저도 이 부분이 비효율적이라고 생각합니다! 그래서 이럴 경우에
peerDependencies를 사용하면 될 것 같아요.
peerDependencies에 대해서 간단하게 설명하면 특정 패키지가 다른 패키지를 필요로 하지만, 그 패키지를 직접 포함하지 않고, 상위 프로젝트(패키지를 설치하는 프로젝트)에서 해당 의존성을 설치하도록 요구하는 방식이에요.
그래서 해당 문제를 해결하려면 peerDependencies를 사용하면 될 것 같은데, 아직 조금 더 공부해보고 의존성 그래프 확인해보고 정리하고 싶어서 이후에 따로 이슈 파서 작업해볼게요! 같이 고민해봐요.
- 각각 필요한 의존이라 문제가 있을 것이라 생각했는데 직접 확인은 못해봤네요..!
apps/extension/package.json
Outdated
| "@eslint/js": "^9.33.0", | ||
| "@pinback/eslint-config": "workspace:*", | ||
| "@pinback/typescript-config": "workspace:*", | ||
| "@pinback/tailwind-config": "workspace:*", | ||
| "@pinback/design-system": "workspace:*", |
There was a problem hiding this comment.
확실히 터보 쓰니까 workspace:* 이 키워드 덕분에 의존성 관리 그냥 바로 깔끔해지네용! 굿
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/extension/src/App.css (2)
2-2: CSS 엔트리 확정 필요: 파일 확장자(.css) 명시 고려번들러/패키지 exports 설정에 따라
@pinback/design-system/styles가 인식되지 않을 수 있습니다. 스타일 파일이styles.css로 노출된다면 확장자를 명시해 호환성을 높이는 것을 권장합니다.적용 예시:
-@import '@pinback/design-system/styles'; +@import '@pinback/design-system/styles.css';확인 요청:
- design-system 패키지의 package.json exports 혹은 style 엔트리가
styles경로를 확장자 없이 노출하도록 설정되어 있는지- Vite/CSS 파이프라인에서 위 경로 해석이 정상 동작하는지 (CI 빌드 성공 외 로컬 HMR 포함)
1-2: Tailwind v4 프리플라이트 주입 확인
shared-styles.css내부에 Tailwind v4 권장 구문인@import "tailwindcss";가 포함되어 있지 않다면, 최상단에 추가해야 합니다. 누락 시 프리플라이트/유틸리티가 적용되지 않을 수 있습니다.필요 시 아래처럼 구성해 주세요(순서: tailwind → shared → design-system):
+@import "tailwindcss"; @import '@pinback/tailwind-config/shared-styles.css'; -@import '@pinback/design-system/styles'; +@import '@pinback/design-system/styles.css';검증 포인트:
- 현재
shared-styles.css가 이미 Tailwind를 import한다면 중복 import가 되지 않도록 한 곳에서만 유지- 브라우저 확장(Extension) 앱의 엔트리(App.tsx 등)에서 이 App.css만을 import하도록 정리되어 있는지 (index.css 중복 import 제거)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
apps/client/src/App.css(1 hunks)apps/extension/package.json(2 hunks)apps/extension/src/App.css(1 hunks)apps/extension/src/App.tsx(1 hunks)apps/landing/src/App.css(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- apps/landing/src/App.css
- apps/extension/src/App.tsx
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/extension/package.json
- apps/client/src/App.css
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#2
File: pnpm-workspace.yaml:3-3
Timestamp: 2025-08-18T13:48:59.021Z
Learning: constantly-dev는 docs 디렉터리를 컨벤션 문서 추가용으로 사용할 예정이라고 명시했습니다.
📚 Learning: 2025-08-19T17:18:57.657Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#5
File: apps/extension/src/index.css:1-1
Timestamp: 2025-08-19T17:18:57.657Z
Learning: constantly-dev는 디자인 시스템 설정 PR 머지 후 `import 'pinback/tailwind-config/shared-styles.css';`를 `app.css`나 `index.css`에서 사용하여 공유 스타일을 관리할 계획입니다.
Applied to files:
apps/extension/src/App.css
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This single import pulls in all of Tailwind's preflight, components, and utilities in one step and is used with the tailwindcss/vite plugin.
Applied to files:
apps/extension/src/App.css
📚 Learning: 2025-07-04T10:12:01.690Z
Learnt from: constantly-dev
PR: Pinback-Team/pinback-client#10
File: apps/landing/src/index.css:1-1
Timestamp: 2025-07-04T10:12:01.690Z
Learning: In TailwindCSS v4, the import "tailwindcss"; syntax is the new recommended approach that replaces the three separate tailwind directives (tailwind base;, tailwind components;, tailwind utilities;). This is used with the tailwindcss/vite plugin.
Applied to files:
apps/extension/src/App.css
🔇 Additional comments (1)
apps/extension/src/App.css (1)
1-2: 공유 Tailwind 스타일 → 디자인 시스템 스타일 순서 적절합니다의도한 전역 스타일 주입 패턴과 일치하고, 다른 앱들과의 정렬도 좋아 보입니다.
3 participants
📌 Related Issues
✅ 체크 리스트
📄 Tasks
+자잘한 의존성 정리 및 스타일 설정 추가!
⭐ PR Point (To Reviewer)
actions를 활용해서 lint/build 관련 CI workflow를 작성했어요.
언제 실행되는가?
branches: main/develop 브랜치에 새로운 코드가 푸시(push)될 때 실행pull_request: 어떤 브랜치에서든 main/develop 브랜치로 풀 리퀘스트(Pull Request)가 생성되거나 업데이트될 때 실행어떤 작업을 하는가?
lint:pnpm run lint명령어를 실행. 이 명령어는 package.json 파일의 scripts 안에 있는 lint 명령(예: "lint": "eslint .")을 찾아 실행하여 코드 스타일을 검사build: lint 작업과 유사하게 build 명령어 실행📷 Screenshot
이렇게 잘 작동합니다~~~ lint와 build 잘 check 되면 머지가 가능하니 확인 필수!!
Summary by CodeRabbit