나만의 전용 템플릿 엔진(?) 제작기 - 초기세팅

개요

최근 사이드프로젝트를 구상하다 보니 막상 떠오른 프로젝트(?)인지 모르겠지만, 나만의 템플릿을 제작해 보면 어떨까? 라는 생각을 많이 하게 되었다.

Nextjs나 React(vite) 템플릿을 보면 공식 문서에서 이미 만들어진 틀을 준다.
사실 베이스부터 시작해서 입맛에 맞춰서 바꿔도 되지만, 아주 귀찮고 재미없는 일인건 알고 있다. 특히 일적으로 바쁜 회사에서 하나씩 뭐 넣고 하는 건 매우 비효율적 (커스텀 웹팩이나 아니면 전사 프로젝트로 진행한다면 다를 수도)
그래서 나만의 템플릿 엔진을 제작해 보기로 하였다
npx create <나만의 템플릿>을 통해서 어디서든지 어느 컴퓨터든지 내가 만들어놓은 lint, prettier 설정 등을 활용할 수 있게 하는 것으로 제작해 볼까 한다.

🚨본 글은 시리즈물로 제작예정입니다 한번에 구성할시 글이 길어질수 있으므로 패키지별로 작성할 예정입니다.

들어가기앞서…

들어가기 앞서서 사전 지식이 필요하다.
현재 템플릿엔진 제작을 위해서는 확장성과 효율을 위하여 모노레포(mono-repo)형식으로 제작할려고한다.
사전지식으로는 모노레포가 필요하니 아래 네이버 D2에서 매우 잘 설명해두었으니 참고바란다.
https://d2.naver.com/helloworld/0923884

왜 모노레포인가? 멀티레포도 가능하지않나?

사실 구성자체는 멀티레포로 진행해두 무관하다
각 react, nextjs 등등의 템플릿을 만들어두고 해두 괜찮지만 상당한 단점이 많이 존재하는데

---

1. 멀티레포는 패키지 관리가 어렵다

패키지관리가 어려운 부분은 바로 공통인 패키지를 관리하기 매우 까다로운 부분이다
쉽게 특정라이브러리를 업데이트할시 특정 프로젝트 버전이 낮으면 오류가 날 확률도 있고,
각 패키지간의 연동이 어느정도인지 파악하기 어렵다

물론 서브모듈(submodule) 같은 방법으로 공통모듈을 넣을순있으나,
이 방법 또한 내부에서 깃 버전을 관리해야되므로 상당한 리소스를 소비할수 밖에 없다.

반면 모노레포는 공통모듈, 혹은 root에 공용 패키지를 정의해 놓으면 각 프로젝트별로 관리할 리소스가 줄어든다
쉽게 공용패키지내에서만 관리하면 되기때문에 관리적 측면에서도 이득이있다.

---

2. 공통인 코드등의 관리가 어렵다

극단적인 예시이긴 하지만 A 프로젝트에서 A 컴포넌트가 쓰인다고 했을 때
B 프로젝트에서도 A 컴포넌트가 쓰인다면 어떻게 처리할 것인가? Submodule? 아니면 공통 모듈 패키지?
이런 식으로 공통인 코드들의 관리가 멀티레포상에서는 상당히 어렵다
막상 A 프로젝트에서만 쓰이는 컴포넌트인 줄 알았으나 다음에 B 프로젝트에서도 쓰인다는 기획이 나왔을 때
(물론 이것도 극단적인 것이고 보통은 공통 모듈로 빼는 편)
그 특정 컴포넌트의 위치가 애매해지는 상황이 발생한다.

반면 모노레포인 경우에는 공용인 부분만 분리하여서 패키지에서 관리하므로 참조 형식으로 사용하면 된다.
얼마나 편한가?

---

3. 개발설정이 매번 달라진다

이 부분은 상황에 따라 다른데
개발 설정이 설정한 사람마다 달라질 수도 있다. 물론 회사 혹은 공통 config설정을 따로 문서화나 코드로 관리한다면 다른 문제지만 그렇지 않다면, 매번 개발 설정이 달라질 수밖에 없다.

이러면 문제점이 바로 설정이 다르니 여기선 동작하던 게 저기선 동작하지 않는 부분이 발생하고, 여기선 괜찮은 lint 설정이지만, 특정 프로젝트는 빡빡하게 해서 빨간줄이 아무 빨갛게 물든 현상을 볼 수 있다.

pnpm workspace? yarn workspace?

사실 2개의 패키지 관리툴을 가지고 고민했었는데
개인적으로 pnpm을 경험해 보고 싶다는 생각이 강하여 채택하게 되었는데
이유는 총 3가지이다

1. yarn berry의 Plug’n’Play(PnP) 방식에 대한 경험 부족
   1. 좋은 기술이긴 하나 개인적으로 패키지 업데이트할시에 zip 파일들의 관리나 이런부분에 대한 부분이 명확하지 않았다. (사실 어떻게 관리할지를 모르겠다.)
   2. 또 좋다고 막상 쓸려니 이게 맞나? 늘어나는 파일들을 보고 의구심이 들었다 → 호환성 이슈도 있고…
2. pnpm의 빠른 속도/캐싱과 의존성관리
   1. 애초에 pnpm 공식 문서에는 ‘빠르고 디스크 공간 효율적인 패키지 관리자’ 라고 적혀있다 그만큼 속도나 디스크 관리에 대해서 자부심이 있다는 생각이 들었다.
      (말로는 2배 빠르다고 하는데 yarn도 npm대비 빠르긴 했었다.)
   2. 그리고 패키지들을 중앙 캐시에 저장하여, 의존성을 심볼릭 링크로 연결하여 중복으로 설치되는 걸 방지해준다.
3. 무엇보다 출시 때부터 workspace 지원하는 부분이 마음에 든다
   1. 대부분 패키지 툴은 일정 버전 이상일 때만 지원을 해줬는데, 출시 때부터 지원해 주었다. (뭐… 후속 주자라 당연한 건가?)

그러므로 이 글에서는 pnpm workspace을사용 할 것이다.

초기세팅

1. pnpm 설치

   node 16 버전이상 필요

    # npm
    npm install -g pnpm
   
    # homebrew
    brew install pnpm

2. 프로젝트 파일 생성

    # 폴더 생성
    mkdir my-monorepo-template
   
    # 폴더들어가기
    cd my-monorepo-template

3. 프로젝트 초기화

    pnpm init

   • init시에 package.json이 생성된다 (추후에 수정예정)

     {
     "name": "my-monorepo-template",
     "version": "1.0.0",
     "description": "",
     "main": "index.js",
     "scripts": {
       "test": "echo \"Error: no test specified\" && exit 1"
     },
     "keywords": [],
     "author": "",
     "license": "ISC"
     }
     

4. 프로젝트 구조

   아래 구조처럼 제작할 예정입니다

    my-monorepo-template/      
    ├── packages/
    │   ├── eslint-config/
    │   ├── prettier-config/
    │   ├── tsconfig/
    │   ├── react-template/
    │   └── nextjs-template/
    ├── package.json
    └── pnpm-workspace.yaml

5. pnpm-workspace.yaml

    packages:
      - "packages/*"
   

마무리

workspace에대해서 공부할수있는 알찬 기회라고 생각이든다
그동안 이런 템플릿 있으면 좋았을거 같다는 생각을 많이 했었고, 찾던 와중에 npx create xxx 같은 명령어를 나두 활용해서 쓸수있다는 부분을 알게 되었다.
나만의 템플릿을 제작하여 새로운 프로젝트를 해볼까한다.
개인적으로 이번엔 서버에 중점을 두기보다 프론트에 더 중점을 둔 방향성으로 만들어야겠다.