Webpack, Babel..... CRA가 있는데 꼭 내가 셋팅해야 할까?!

지난번까지 Webpack, Babel의 기본적인 코드들을 직접 세팅해보며 React 앱의 초기설정을 마쳤다.

 

일단 나는 기존에 진행중이던 프로젝트를 CRA(Create React App)으로 생성했었다.

처음 시작할 때는 늘 그렇듯 아무 문제가 없었다.

하지만, 실전 리액트 프로그래밍의 책 내용을 인용하면

리액트로 개발을 하다 보면, 개발자 대부분이 바벨 설정 때문에 애를 먹는다.
보통 인터넷에 떠도는 바벨 설정을 무분별하게 가져오기 쉽다.
그 코드는 한동안은 잘 돌아가는 듯 보이지만 예상치 못한 상황에서 문제가 발생하기 마련이다.

 

그리고 이 상황은 나에게도 일어났다. (하지만... 어쩌면 일어나지 않았을지도 모른다..!)

이유를 알 수 없는 에러가 발생했고, 내가 이것저것 온갖 설정을 막 건드렸기 때문이라고 추측했다.

그래서 이참에 웹팩을 공부해야겠어! 라고 생각하고, 책을 펼쳤고 코드를 따라 쳐 봤다.

그렇게 기본적인 설정은 마쳤다.

 

근데 계속 의문점이 생기는거다. 필요성을 떠나서, 내가 웹팩과 바벨을 공부해야하는 이유는 알겠다.

CRA 프로젝트에도 이미 webpack과 babel 설정이 되어있는 상태이고,

어떤 문제에 맞닥트렸을 때 적어도 코드를 이해하고 문제점을 인지할 수 있어야겠지.

 

근데 그렇다고 해서, 간-단한 CRA를 두고 Webpack을 사용해서 프로젝트 설정을 해야 하나? 정말? 🤷🏻‍♀️ 

내 입맛대로 리액트를 세팅하고, 더 딥하게 잘 사용하기위해서 라고 하지만 구체적인 예시가 필요했다.

 

그래서 구글링하며 여러 글들을 읽었고, 공식문서에서도 찾아본 내용들을 정리해보려고 한다.

 

 

---

👉🏻 webpack.config.js 파일을 실행 mode에 따라 각각 적용할 수 있다. (--development, --production)

웹팩4 버전부터는 개발 환경과, 프로덕션 환경을 분리해서 사용할 수 있다. 각각 적용되는 옵션이 다르다.

추가적으로 특정 모드에서만 수행할 코드를 따로 입력해줄 수 있다.

module.exports = (env, options) => {
  //...

  if(options.mode === 'development') {
    // Development 설정
  } else {
    // Production 설정
  }

  return config;
}

 

 

👉🏻 webpack-dev-server 를 사용을 위한 devServer를 직접 세팅할 수 있다.

  devServer: {
    publicPath: '/',          // 브라우저에서 접근하는 path (기본값 '/')
    port: 8080,               // 개발서버 포트 (기본값: 8080)
    historyApiFallback: true, // 404 응답 시 index.html로 리다이렉트
    hot: true,                // Hot Module Replacement
  }

CRA로 만들어진 리액트 프로젝트를 eject 해서 까보면 아래와 같이 기본 설정돼있는걸 볼 수 있다.!

webpack의 DevServer API가 제공하는 프로퍼티(?) 들은 아래 공식문서에서 확인할 수 있다.

DevServer | webpack

 

 

👉🏻 webpack의 splitChunks 기능을 통해, 여러 가지 번들 파일을 만들 수 있다.

splitChunks를 이용하면, 중복 사용된 모듈들을 추출해 다른 번들링 파일로 만들게 된다. 

이것 역시 CRA eject를 까보면 아래와 같이 설정돼 있다.

이를 직접 커스텀함으로써 대형 프로젝트에서, 번들 파일을 더 적절히 분리하고 나눌 수 있다.

SplitChunksPlugin | webpack

.. 근데 너무 어렵다. 이렇게까지 직접 사용해보지 못해서 솔직히 와닿지가 않는다.

하지만, 이런 셋팅들을 통해 궁극적으로는 성능을 개선하고자 하는 것 같다고 생각했다.

---

 

💁🏻‍♀️ 결론

 

이번에 webpack을 공부하면서, CRA의 eject으로 기본 설정 코드를 보면서,...

커스텀을 하려면 기존에 CRA에서 제공해주었던 이 많은 설정들을 다 해야하는건가?

혹은 기존 CRA에서 제공해주던 이 많은 것들을 다 쓰지 않으니, 안 쓰는 걸 찾아서 빼야하는건가?

CRA를 사용하지 않음으로써 새로운 할 일이 많아지는 데에 막막함이 앞섰다.

 

웹팩과 바벨의 공부는 분명 필요할 것이다. 하지만 개발을 반드시 이렇게 해야 하는건가? 다들 이렇게 하는 걸까?

하는 생각으로 구글링을 많이 해봤지만 사실 웹팩, 바벨 초기 설정글이 대다수이고 나의 궁금증을 시원하게 해소해주는 글은 없었다..

 

아마 추측컨대, 실제 서비스에서는 용량도 성능도 중요하니까

꼭 필요한 코드들만 사용하고, 최종 압축되는 번들 파일의 용량을 최소화하고자하는 것이 아닐까?

 

그러니까 결국 나도 배우고 잘 사용해야 하는게 맞는 것 같다. &_&

아직 눈곱만큼밖에 모르지만, 계속 부딪혀보며 배워나가야겠지!

 

---

+) 위에서 CRA의 설정을 열어보기 위해 Eject을 사용했다.

npm run eject
yarn eject

CRA 프로젝트에서 숨겨져있던 모든 설정들(webpack, babel, ...)과 패키지들의 의존성을 볼 수 있다.

eject을 수행하면, eject 이전 상태로는 되돌아갈 수 없고, CRA가 수행해주던 많은 작업들을 직접 수정해야한다!

 

하지만 꼭 CRA에서 건드려야할 게 생긴다면.. customize-cra , react-app-rewired 같은 eject하지 않고 수정할 수 있게 도와주는 라이브러리를 사용해도 좋을 것 같다. 하지만 이 라이브러리들이 안정성을 보장해줄 순 없다.. (그리고 어쩌면 아예 수정이 불가능한 설정이 있을 수도 있겠다)