위의 게시물을 작성하고 문제가 발생하였다. 바로 ts-loader에서 하는 타입체킹이 local에서는 통과하지만 github action, jenkins와 같은 ci tool에서는 이상한 곳에서 타입에러가 발생하였다.
emotion을 이용할때 theme에 대해서 선언병합을 이용하여 타입을 지정해주었는데 ci tool에서는 선언 병합을 인식을 못하는것같다.
그래서 어쩔수 없이 ts-loader를 제거하거나 개선이 필요하였는데 타입체킹을 포기하는것은 너무 리스크가 큰것 같았다.
🔨 dev, prod -> local, dev, prod
원래 dev, prod 2개로 웹팩을 나누어서 관리하여 실제 local에서 실행하는 설정과 dev 서버에서 실행하는 설정이 동일하였습니다.
그래서 ts-loader가 ci에서 되지 않는 문제를 local, dev, prod 3개의 설정으로 분리하여 관리하였습니다.
-
local: yarn start를 할시 참고하는 설정, 이때 ts-loader를 이용하여 rebuild시 마다 타입체킹을 진행
-
dev: yarn build-dev를 할시 참고하는 설정, develop에 push를 하게 될시 build-dev를 이용하여 dev server에 반영
-
prod: yarn build를 할시 참고하는 설정, main에 push를 하게 될시 build를 이용하여 prod server에 반영
이렇게 분리를 하면 ci툴을 이용하는것은 실제로 배포를하는 dev, prod이기 때문에 타입에러가 나지 않고 local에서만 타입체킹을 할 수 있도록 할 수 있었습니다.
또한 local, dev, prod 각각의 역할이 다르기 때문에 분리의 필요가 있다고 생각하였습니다.
⚙️ dev에서의 optimize
실제로 dev, prod 설정의 차이는 무엇이 있을까요? 둘 다 배포를 하는 설정이기에 mode: production 등이나 기본 설정을 동일합니다. 다른거라고는 .env 밖에 없습니다.
하지만 dev에서의 빌드속도를 단축할 수 있는 방법이 있습니다. 바로 webpack.dev.js 에서 optimization의 minimize옵션을 false로 명시하는것이죠!
원래 production mode에서는 기본적으로 minimize가 true로 설정되기 때문에 난독화와 압축을 진행합니다. 하지만 이러한 작업자체가 빌드속도에 큰 영향을 미칩니다.
사용자가 이용하지 않는 dev sever에서는 굳이 minimize가 필요하지 않기 때문에 false로 줄시 빌드속도가 대폭 향상되는것을 확인할 수 있습니다.
결과: 11초 -> 6초💡
💾 cache의 filesystem
dev와 prod의 빌드 속도를 비약적으로 증가시킬 수 있는 방법이 있다. 바로 cache를 이용하는 것이다.
캐시에 관련된 공식문서를 보자. development에서는 default로 memory라는 값으로 설정되어 있지만 production mode에서는 false라고 한다.
그렇다면 development와 production의 cache에 filesystem을 설정하면 캐시가 적용될까?
맞다!! 물론 첫 빌드 속도는 동일하겠지만 그 뒤부터는 빌드 속도가 매우 빠르게 된다.
이것을 적용하면 무려 개발환경에서의 빌드시간이 1초까지 줄어든게된다.
결과: 6초 -> 1초💡
