webpack 라이브러리 걷어내고 커스텀하기

담당하고있던 서비스에서 webpack 설정이 복잡하고 까다롭기 때문에 webpack 설정 + 개발환경을 도와주는 라이브러리 roadhog를 사용했다. 계속 사용해도 나쁘지 않았지만, 서비스가 커지면 커질수록 문제점이 생겼다.

 

roadhog npm(참고)

https://www.npmjs.com/package/roadhog

 

문제점은

webpack 설정에 관련된 af-webpack 과의 강한 의존성

roadhog는 업데이트가 더이상 되지 않아 많은 패키지들이 더이상 호환되지 않는다.

중국어로 된 docs. 영어docs 는 매우 불친절...

사용하는 사람이 적어 정보를 찾기가 힘듬.

등이 되겠다.

 

지금까지 왜 걷어내지 않았는가?

를 생각해보면, 서비스가 커지면 커질수록 기본 환경을 전부 설정하고있는 roadhog를 걷어내는 것은

변경 후 SideEffect가 너무 클 것으로 예상되고, 

webpack, babel... 환경설정에 대해 깊은 이해력을 가진 사람의 부재이고,

지금으로도 잘 작동했기 때문에 걷어내지 않았던 거 같다.

하나로 더 많은 시간이 소요되기도 하기 때문에, 서비스에 여유있는 시기가 아니라면 어려웠을 것이다.

 

 의존성이 강하다 보니 webpack 내 플러그인들의 버전이 너무 낮아 새로운 기술들을 도입할 때 점점 문제가 생기기 시작했다. roadhog 내에서 사용하는 af-weback, 그리고 그 내부에서 사용하고있는 uglify-webpack-plugin 의 버전이 너무 낮아 web3 컴파일이 어려워 에러를 배출해냈고, 이걸 해결하는 방법은 내부의 uglify-webpack-plugin의 버전을 올려주고 해당 버전 사용법으로 코드를 바꿔주는 방법을 임시방편으로 사용하기로 했다. (개발서버에서만 사용) 이 계기로 roadhog를 걷어내는 것을 추진하게 되었다.

 

걷어내기 위한 준비물

roadhog 

> webpack, babel, 개발환경에 대한 이해이다.

 

현재 로컬서버 세팅, 빌드 후 개발서버 배포 테스트까지 완료 되었고, 

기존 서비스 총 로딩 시간이 6.3s -> 0.9s 까지 단축되어 성능이 5s 이상 개선되었다. 기존의 사이트가 너무 느린 것도 있었지만 많은 속도가 개선되어 뿌듯했다. 

 

 

개발 과정에서 만났던 에러들/배웠던 점들을 하나하나 짚어보며 포스팅하도록 하겠다.