하리하링웹

현재 사용하고 있는 빌더에서 번들링 작업 시 멀티프로세스를 사용하고 있지만, Jenkins 빌드 머신의 24개 코어를 충분히 활용하지 못해 빌드 시간이 오래 걸리는 문제가 발생하고 있다는 사실을 찾아냈다. 기존 빌더에서는 워커 개수를 4개로 하드코딩하여 사용하고 있었기 때문에 발생한 문제이며 이를 개선하기 위해 다음과 같은 작업을 진행했다.CPU 코어 수에 맞춘 워커 개수 증가 먼저 os.cpus().length;를 사용하여 CPU 코어 개수를 얻고, 해당 개수만큼 worker-pool의 개수를 증가시켜 효율을 높였다.const numWorkers = os.cpus().length; 청크 분배 방식 개선 위의 CPU 코어에 맞게 워커 개수를 늘리는 작업 자체는 쉬운 작업이지만 이 때 문제가 발생한 부분이..

tsc는 컴파일시에 사용하지 않더라도 import 된 경로가 있다면 해당 경로의 타입에 문제가 있는지 없는지를 진단하는 과정을 거친다. (단 컴파일 결과에서는 제외됨) 사용하지 않는 import가 있고 만약 파일들이 많이 얽혀있다면 이로 인해 tsc 컴파일 시간이 증가할 가능성이 있다. 따라서 사용하지 않는 import 구문들을 제거한다면 tsc 컴파일 시간이 감소될것이라고 추측하였으며 이를 eslint를 사용하여 제거한 뒤 테스트를 진행해보기로 결정하였다. import와 관련된 eslint plugin는 여러가지가 있지만 기존 eslint rule의 변경이 필요한건 아니며 순수하게 unused import와 관련된 작업만 필요하기에 이와 딱 맞는 eslint plugin을 설치찾아 설치해준다. 이 경우..

타입 스크립트 컴파일 시 declaration 옵션을 키면 컴파일 속도가 빨라질까? 최근 빌더 개선 작업을 하고있는데 통한 컴파일 시 타입 진단 작업이 너무 오래걸려 해당 시간을 줄이기 위해 가설을 하나 세웠다. 용량이 큰 모듈의 tsconfig에서 declaration 옵션을 켜서 컴파일 시 .d.ts 파일을 생성하게 해주고 이후 타입 진단 과정에서 이를 참조해서 타입을 진단하면 컴파일 속도가 빨라질 수도 있다, 그리고 이는 d.ts 파일을 생성하는데 걸리는 시간과 참조 타입을 사용하여 감소하는 시간을 적절히 고려해야한다는 가설이다. 이 글은 이 가설을 검증하기 위한 글이다. 가설큰 디렉토리를 컴파일할 때 해당 디렉토리에 d.ts 파일을 추가해 컴파일하면 d.ts 파일을 생성한 뒤 타입 진단을 진행하기..

개요웹 애플리케이션에서 초기 렌더링이 늦어지는 문제의 원인은 매우 다양하다. 이번에 해결한 이슈는 그 중 하나인 번들 사이즈 관련 문제이다. 일반적으로 개발자들은 다양한 오픈소스 번들러나, 경우에 따라서는 직접 개발한 번들러를 사용하여 자바스크립트 파일을 번들링한다. 그렇다면 왜 번들링 과정이 필요할까? 적절히 큰 규모의 프로젝트에서는 코드의 양이 수 기가바이트, 많으면 수십 기가바이트에 이를 수 있다. 사용자가 프로그램에 접속할 때 마다 모든 코드를 한 번에 가져오는 것은 현실적으로 부담이 너무 크기 때문에, 번들러에서는 이 과정에서 중복되는 코드 혹은 현재 상황에 필요 없는 코드를 제거하는 트리쉐이킹(Tree-shaking) 과정을 거친다. 이를 통해 큰 사이즈의 코드들을 아주 작은 단위로 줄여서 가..

회사의 번들링 결과 파일에서 중복된 Object.spread 함수가 생성되고 있는것을 확인하였다. 같은 번들임에도 중복 함수가 생성되고 있었으며 번들의 크기가 큰 경우 100~200개 까지도 중복 함수가 이름만 바뀌어 생성되는 것을 확인하였으며 이는 파일의 크기를 불필요하게 키우는 문제를 야기하기 때문에 이를 해결하기 위한 원인을 찾아보았다.문제 예시아래 예시는 중복된 _object_spread 함수들이 각각의 이름만 달리하여 생성된 예시이다.function _object_spread$3O(target) { for (var i = 1; i 원인중복된 _object_spread 함수의 생성 원인을 분석하기 위해 아래와 같은 코드를 작성하여 번들링을 진행해봤다.jsxCopy codeconst objec..