모노레포 구조 및 배치
하나의 Git 저장소 안에서 프로젝트, 패키지 및 공유 코드를 구성하는 모범 사례를 학습합니다.
모노레포 구조 및 배치은(는) CoddyKit의 무료 Git Advanced: Monorepo, Submodules & Workflows 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Git Advanced: Monorepo, Submodules & Workflows 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Git Advanced: Monorepo, Submodules & Workflows 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
Why Structure Matters
Welcome! In a monorepo, many projects live together in one place. A clear, thoughtful structure is super important for keeping things organized.
It helps developers quickly find what they need, promotes code sharing, and makes managing the entire codebase much easier as it grows.
The Monorepo Root
At the very top level of your monorepo, the root directory, you'll find files that apply to the entire repository. Think of them as global settings.
.git/: Git's internal tracking files..gitignore: Tells Git which files to ignore.README.md: The main description of your monorepo.package.json: (If using Node.js) Monorepo-level scripts or dependencies.tools/: Global utility scripts.
Grouping Projects: `apps` and `packages`
To keep things tidy, projects are usually grouped into top-level directories based on their type or purpose. The most common ones are apps/ and packages/ (sometimes libs/).
apps/: For deployable applications like web apps, mobile apps, or API services.packages/(orlibs/): For reusable libraries, components, or shared utilities that multiple apps might use.
This clear separation helps you understand a project's role at a glance.
Inside the `apps` Folder
Each folder within apps/ represents a distinct, standalone application. They usually have their own source code, configuration, and dependencies.
monorepo/
├── apps/
│ ├── web-app/ # Your frontend application
│ │ ├── src/
│ │ └── package.json
│ ├── api-service/ # Your backend API
│ │ ├── src/
│ │ └── Dockerfile
│ └── mobile-app/ # Your mobile application
│ ├── src/
│ └── ...
└── ...This structure keeps each application isolated while being part of the larger monorepo.
Inside `packages` (or `libs`)
The packages/ (or libs/) directory is where you put all your reusable code. These are often smaller, focused libraries or UI components that can be shared across multiple applications.
monorepo/
├── packages/
│ ├── ui-components/ # Reusable UI library
│ │ ├── src/
│ │ └── package.json
│ ├── shared-utils/ # Common utility functions
│ │ └── src/
│ └── auth-lib/ # Authentication logic
│ └── src/
└── ...This promotes code reuse and consistency across your projects.
Centralized Configuration
To ensure consistency, many monorepos centralize configuration files for tools like linters (for code style), formatters (for code layout), and build systems.
monorepo/
├── .eslintrc.js # Linter configuration
├── prettier.config.js # Code formatter configuration
├── jest.config.js # Test runner configuration
├── tsconfig.base.json # Base TypeScript config
└── ...These files often live at the root or in a dedicated config/ folder, applying rules consistently to all projects.
Benefits of Good Structure
A well-defined monorepo structure offers significant advantages:
- Discoverability: New team members can quickly understand where everything is.
- Consistency: Enforces uniform project layouts and coding standards effortlessly.
- Maintainability: Makes refactoring and managing dependencies much simpler.
- Tooling: Streamlines setup for monorepo-aware build and development tools.
It's an investment that pays off in the long run!
A Simple Program Example
While monorepo structure is about organizing files and folders, here's a basic Java program to demonstrate how runnable code appears in CoddyKit. This helps you get comfortable with the editor!
public class MonorepoConcept {
public static void main(String[] args) {
System.out.println("A well-structured monorepo is great!");
}
}Naming Conventions
Clear and consistent naming is crucial in a monorepo. It helps avoid confusion and makes the codebase more readable.
- Kebab-case: Use
kebab-casefor project and folder names (e.g.,web-app,shared-utils). - Specific names: Avoid generic names like
utils; be more specific (e.g.,date-utils,api-client). - Prefixes: For larger organizations, consider prefixing shared packages (e.g.,
@myorg/ui-components).
Monorepo Organization Check
Consider a monorepo containing a web application, an API service, and a shared UI component library. What are common and effective ways to organize these projects?
Recap: Structured Monorepos
Fantastic work! Today, we learned the importance of structuring a monorepo. We covered organizing applications into apps/, shared libraries into packages/ (or libs/), and centralizing global configurations.
A well-defined layout makes your monorepo easier to navigate, more consistent, and simpler to maintain. Next, we'll dive into specific tools that help manage these complex structures!
자주 묻는 질문
“모노레포 구조 및 배치” 강의는 무료인가요?
네 — “모노레포 구조 및 배치” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Git Advanced: Monorepo, Submodules & Workflows 강의 전체를 잠금 해제할 수 있습니다. Git Advanced: Monorepo, Submodules & Workflows 강의에는 총 4개의 강의가 포함되어 있습니다.
“모노레포 구조 및 배치”에서 뭘 배우나요?
하나의 Git 저장소 안에서 프로젝트, 패키지 및 공유 코드를 구성하는 모범 사례를 학습합니다. 브라우저에서 직접 실행하는 실습 코드로 Git Advanced: Monorepo, Submodules & Workflows을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Git Advanced: Monorepo, Submodules & Workflows을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Git Advanced: Monorepo, Submodules & Workflows은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.
“모노레포 구조 및 배치” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Git Advanced: Monorepo, Submodules & Workflows 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Git Advanced: Monorepo, Submodules & Workflows 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 모노레포란 무엇인가요?
- 모노레포 구조 및 배치
- 모노레포 도구 소개
- 모노레포와 폴리레포: 접근 방식 선택