설정 지옥

이번 프로젝트를 CRA 를 사용하지 않고 진행해보기로 했다.

왜 CRA를 쓰지 않고 했냐면

1. 예전부터 npm eject의 정체가 궁금했다.
2. npm start가 어떻게 devServer를 구동하고, 번들링을 하는지 궁금했다.
3. 기존에 배운 지식들(Webpack, babel 등)을 스스로 적용해보고 싶었다.

적용하려는 기술 스택

• Webpack
• Eslint
• Babel
• Tailwind( + PostCSS )

적용에 어려웠던 점

1. 설정이 서로 엮이고 엮인다.
2. preset과 plugin이 너무 세분화되어 많이 존재한다.
3. 실제 작동이 뒷편에 숨겨져 있어 마음이 불안하다.

한마디로 설정을 하는 데 너무 복잡하고 오랜시간이 걸린다. 물론 처음이라 그런지도 모르겠다. 하지만 내가 그 내부를 잘 모르는 기술들이 서로 엮여서 어떤 충돌을 일으키고 그걸 고쳐나간다고 생각하니 어지러웠다. 수많은 package를 설치하는데 잘 모르고 이렇게 무작정 실행만 되면 괜찮나하는 죄책감도 들었다.

Webpack

“webpack”: “^5.65.0”,
“webpack-cli”: “^4.9.1”,
“webpack-dev-server”: “^4.7.2”
“@svgr/webpack”: “^6.2.0”,
“babel-loader”: “^8.2.3”,
“css-loader”: “^6.5.1”,
“postcss-loader”: “^6.2.1”,
“style-loader”: “^3.3.1”,
“ts-loader”: “^9.2.6”,
“html-webpack-plugin”: “^5.5.0”,

웹팩에 대해서는 예전에 인프런을 통해서 강의를 들었다. 다만 돌이켜보면 너무 이른 시기에 강의를 수강했다는 생각이 들었다. NodeJs에 대해서 이름만 들어본 정도였고 번들링이니 트랜스파일링이니에 대해서 거의 모르던 시기였다. 조금 더 지식을 쌓고서 이번에 들여다보니 웹팩이 하는 일을 대략적으로나마 이해하겠다는 느낌을 받았다.
물론, 이해도와는 별개로 너무 많은 loader와 plugin이 필요해서 어지러웠다. 여러 블로그와 사이트를 참고한 결과 plugin은 결과물을 처리하고 loader은 파일단위로 번들링을 수행한다고 한다.
설정하는 내내 웹팩 공식 문서를 읽다가 바벨 문서를 읽다가 계속 반복이었다. 프로젝트를 제대로 하기도 전에 기운이 쪽 빠졌다. 왜 CRA로 리액트 프로젝트를 하는지 알 것 같았다.

참고

• 웹팩의 기본 개념 | 김정환 블로그
• React + Typescript + Webpack + Babel 초기 셋팅하기(1)
• 2019.07.11 React + TypeScript + Webpack 환경 설정 :: 이뇽의세상

Babel

Packages

“@babel/cli”: “^7.16.7”,
“@babel/core”: “^7.16.7”,
“@babel/plugin-transform-runtime”: “^7.16.10”,
“@babel/polyfill”: “^7.12.1”,
“@babel/preset-env”: “^7.16.7”,
“@babel/preset-react”: “^7.16.7”,
“@babel/preset-typescript”: “^7.16.7”,
“@babel/runtime”: “^7.16.7”,

babel의 preset과 plugin이 너무 번거롭다고 느껴졌다.
필요에 따라서 선택적으로 골라 plugin이나 preset을 사용할 수 있는 점은 좋지만, 너무 세분화되어서 복잡하게 느껴졌다. Async-Await 문법을 쓰려고 했는데도 ‘core’나 ‘preset-env’에서는 지원하지 않아서 ‘runtime’을 또 설치했다. 어떤 preset이랑 plugin이 무얼 지원하고 안하는지 실제 개발자들은 다 알고 있는 걸까하는 조바심도 들었다.

참고

babel.config.js 파일과 .babelrc 차이점
Babel 바벨 설정 방법 (1) - 전체설정파일 , 지역설정파일
Babel 모르고 사용하던 Babel. 이젠 두려워 마세요. - Babel 알아보기

Eslint

Packages

“eslint”: “^8.6.0”,
“prettier”: “^2.5.1”,
“@typescript-eslint/eslint-plugin”: “^5.9.1”,
“@typescript-eslint/parser”: “^5.9.1”,
“eslint-config-prettier”: “^8.3.0”,
“eslint-plugin-prettier”: “^4.0.0”,
“eslint-plugin-react”: “^7.28.0”,

Eslint도 딱히 프로젝트에 적용시켜 본 적이 없어서 시험삼아 적용시켜 보았다. eslint에도 플러그인이 존재했다. 유명한 플러그인으로는 airBnB가 있는데, 혼자서 튜토리얼 느낌으로 진행하는 프로젝트이므로 따로 적용하지는 않았다.
Prettier와 설정이 겹치는 경우가 있어서 그와 관련된 plugin을 추가적으로 설치했다.
한편으로 typescript를 이번에 사용하는 까닭에 Eslint까지 과연 필요했을까하는 의심이 남는다.

Tailwind( +PostCss)

Packages

“tailwindcss”: “^3.0.15”,
“postcss”: “^8.4.5”,
“autoprefixer”: “^10.4.2”,
“postcss-preset-env”: “^7.2.3”,

나름대로 핫(?)하다는 스타일링 기술을 도입해봤다.
React-Bootstrap 은 개인적으로 컴포넌트를 다루는 방식이나 네이밍 룰이 마음에 들지 않았다. React가 state를 다루는 방식도 아니고 css도 아닌 것이 어딘가 애매한 느낌이 들어서 사용이 불편했다.
Material UI는 너무 방대한 라이브러리였다. 지금 프로젝트에는 도입할 필요가 없을 듯 하여서 inline-style과 비슷하고 비교적 러닝 커브가 낮은 Tailwind를 선택했다.
Tailwind에도 tailwind.config.js라는 설정 파일이 따로 존재했다. 또한 Tailwind 의 전처리 과정을 위해서는 PostCss를 설치하고, 번들링을 위해 다시 Webpack에 postcss-loader를 설치해 css파일을 처리해야했다.

결론

CRA와 그 template은 정말 편리한 툴이었다는 사실을 깨달았다.
하지만 아무것도 모르고 제공해주는 툴을 사용하는 것보다 CRA로 만든 프로젝트와 비슷하게나마 구현하는 시도를 통해 내부의 작동방식을 자세히 들여다 볼 기회였다. 물론 또 그 기술들의 내부를 모르다 보니 양파 껍질을 까는 것마냐 계속 안쪽으로 파고 다시 파고...
여튼 이쯤에서 설정에 관해서는 마무리 짓고 차후에 필요에 의해서 찬찬히 들여다 보는 시간을 가지면 좋을 것 같다는 생각이 들었다.

트리비아

Webpack을 사용하기 위해 다방면으로 알아보던 중 Vite란 새로운 빌드툴이 나왔다는 사실을 접했다. 다음에는 Vite를 통해 프로젝트를 진행해보아도 좋을 듯 하다. Vite는 번들링을 Rollup을 통해 한다고 하는데 나중에 또 들여다 봐야겠다.

기타 설정과 관련된 참고

typescript-react svg를 import 하는 방법