하리하링웹

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

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

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