Lighthouse of FE beginner

Intro이번 Vite PoC가 성공적으로 끝나면서 babelrc (혹은 babel.config.js) 파일을 걷어냈고 프로젝트에서 바벨 설정을 따로 하고 있지 않고 Vite 플러그인에 모든 일들을 위임하고 있습니다. 이런 상황에서 babel을 걷어내고 SWC를 도입을 하면 어떨까라는 생각이 들었고, Vite의 훌륭한 생태계로 인해 플러그인을 교체해 주는 것만으로도 손쉽게 SWC가 도입이 가능하기에 PoC를 진행했습니다. SWCSWC란 Speedy Web Compiler의 약자로써 Rust로 작성된 웹 애플리케이션 컴파일러입니다. SWC는 최신 사양의 JavaScript 코드를 브라우저 호환성을 위해 이전 사양의 코드로 트랜스파일 하거나, TypeScript 코드를 JavaScript로 컴파일 해주는 등..

이전에도 동일한 방법으로 번들링 최적화를 했던 경험이 있습니다. 이번 프로젝트에서도 마찬가지로 번들링 최적화를 위해 아래 작업을 거쳤습니다.https://velog.io/@kangactor123/Vite-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%B2%88%EB%93%A4%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94 Vite 프로젝트는 SPA 아키텍쳐이기 때문에 번들링 최적화를 해줘야 합니다. Vite는 개발 서버 구동을 위해 ESbuild와 네이티브 ESM을 사용하고 있고, 프로덕션 번들링을 위해 rollup이라는 번들러를 사용하고 있습니다. RollUp의 번들링 방식은 웹팩의 번들링 방식과 다릅니다. 초기에 소스 코드를 동일한 수준으로 (호이스팅이나..

들어가며보통의 리팩토링 작업은 그다지 큰 단위의 작업이 아니기에 회고를 작성하지는 않지만 이번 Vite 마이그레이션 작업은 정말 크고 중요한 리팩토링이자 리팩토링의 최종 목표였기 때문에 회고 글을 작성한다. 4월 중순에 팀에 합류하고 프로젝트를 살펴보고 Vite로 마이그레이션 하면 좋겠다 라는 생각을 했다. 더불어 React와 TypeScript 버전도 최신 버전으로 버전 관리를 해야겠다는 생각도 들었다. 그 이유는 다음과 같았다.너무 오래 걸리는 개발 서버 구동시간오래 걸리는 빌드 시간그 당시 최적화는 됐지만 eject된 CRA는 버전 관리가 어렵고 프로젝트의 복잡도만 늘어난다.메인 라이브러리인 React와 TypeScript의 버전 관리가 안돼서 서드 파티 라이브러리의 버전 관리 또한 안됨. 이럴수록..

기대 효과더 이상 유지보수 되지 않는 CRAVite는 ESModule을 활용하기 때문에 로컬에서 개발 서버를 실행 시 번들링 없이 빠르게 시작이 가능 (대기시간 감소)빠른 소스 코드 갱신CRA는 개발 시 소스 코드를 변경하면 모든 파일을 다시 번들링을 수행하기 때문에 페이지가 리로드가 됨.Vite는 ESM을 이용해 수정된 모듈만 교체하기 때문에 코드 수정이 갱신 시간에 영향을 미치지 않음. 또한 HTTP 헤더를 활용해 모듈을 캐싱하여 페이지의 로드 속도를 높여줌.빌드 시간 감소개발서버, 프로덕션, 빌드에 필요한 옵션을 별도의 리소스 투입 없이 config 파일로 설정이 가능해 개발 비용 감소 Vite 마이그레이션 전 고려해야 할 사항Node.js 버전 (최소 18버전을 요구)Eject 하여 설정한 부분들..