grace's dev_note

프로덕션 버전으로 빌드하고자 한다면 vite build 명령을 실행해주세요. 빌드 시 기본적으로 /index.html 파일이 빌드를 위한 엔드 포인트로 사용되며, 정적 호스팅을 위한 형태로 진행됩니다. 브라우저 지원 현황 빌드된 프로덕션 버전의 경우 모던 Javascript를 지원하는 브라우저에서 동작한다고 가정합니다. 빌드된 프로덕션 버전은 모던 Javascript를 지원하는 환경에서 동작한다고 가정합니다. 따라서 Vite는 기본적으로 네이티브 ES 모듈, 네이티브 ESM의 동적 Import, 그리고 import.meta를 지원하는 브라우저를 타깃으로 하고 있습니다. 만약 자바스크립트 타깃을 지정하고자 한다면, build.target 설정을 이용해주세요. 다만 버전은 최소한 es2015 이상이어야 합니..

URL을 통해 에셋 가져오기 정적 에셋을 가져오게 되면 에셋에 접근할 수 있는 URL이 반환됩니다. import imgUrl from './img.png' document.getElementById('hero-img').src = imgUrl 예를 들어, imgUrl 객체는 개발 시 /img.png 값으로 할당되지만, 실제 프로덕션 버전에서는 /assets/img.2d8efhg.png와 같은 값이 할당됩니다. Webpack의 file-loader와 비슷한데, 하나 차이점이 있다면 vite는 절대 경로와 상대 경로 둘 다 사용할 수 있습니다. url()로 참조되는 CSS의 경우 동일한 방식으로 동작합니다. 일반적인 이미지, 미디어, 폰트 파일 타입은 자동으로 에셋 목록에 포함됩니다. 물론 assetIncl..

vite는 몇 가지 추가적인 vite 전용 옵션과 함께 잘 설계된 rollup의 플러그인 인터페이스를 기반으로 하는 플러그인들을 사용하여 확장할 수 있습니다. 이는 vite 사용자가 필요에 따라 개발 서버나 SSR과 같은 기능들을 확장할 수 있는 것과 동시에, 검증된 rollup 플러그인 생태계에도 의존할 수 있음을 의미합니다. 플러그인 추가하기 플러그인을 사용하려면 프로젝트의 devDependencies에 플러그인을 추가하고, vite.config.js 설정 파일의 plugins 배열에 해당 플러그인을 포함시켜야 합니다. 예를 들어, 레거시 브라우저에 대한 지원을 제공하기 위해 공식 플러그인 중 하나인 @vitejs/plugin-legacy를 사용하고자 한다면 다음과 같이 할 수 있습니다. // vit..

기본적으로 vite는 여타 정적 파일 서버와 크게 다르지 않습니다. 다만, vite는 네이티브 ESM 말고도 기존 번들러에서 제공하던 기능을 대부분 지원하다는 차이점이 있습니다. NPM을 이용한 디펜던시 import 그리고 사전 번들링 다음 코드는 네이티브 ES에서 정상적으로 실행되지 않습니다. import { someMethod } from 'my-dep' 모듈의 위치를 찾을 수 없기 때문인데, vite는 다음을 기준으로 모듈을 가져오기 때문에 위 코드 역시 정상적으로 실행됩니다. Vite를 통해 ESM 스타일로 사전에 번들링된 CommonJS 및 UMD(CommonJS와 AMD 스타일의 모듈을 둘 다 지원하는 형태) 모듈. 이 과정은 Esbuild를 통해 이루어지며, 자바스크립트 기반의 다른 번들러보..

들어가기 전에 Vite는 프랑스어로 빠르다를 의미합니다. 빠르고 간결한 모던 웹 프로젝트 개발 경험에 초점을 맞춰 탄생한 빌드 도구이며, 두 가지 컨셉을 중심으로 하고 있습니다. 개발시 네이티브 ES Module을 넘어 더욱 다양한 기능을 제공합니다(HMR 같은). 번들링 시 Rollup 기반의 다양한 빌드 커맨드를 사용할 수 있습니다. 이는 높은 수준으로 최적화된 정적 리소스들을 배포할 수 있게 하며, 미리 정의된 설정을 제공합니다. vite는 기본적으로 최적화된 설정을 제공하지만, Plugin API 또는 Javascript API를 사용할 수 있습니다. 물론, 타입스크립트도 지원합니다. 지원하는 브라우저 기본적으로 네이티브 ES 모듈, 네이티브 ESM의 동적 Import, 그리고 import.met..

이런 문제점이 있었어요 브라우저에서 ESM을 지원하기 전까지는, 자바스크립트 모듈화를 네이티브 레벨에서 진행할 수 없었습니다. 따라서 개발자들은 번들링이라는 우회적인 방법을 사용했습니다(Webpack 같은). 하지만 애플리케이션이 점점 더 발전함에 따라 처리해야 하는 자바스크립트 모듈의 개수도 극적으로 증가하고 있습니다. 심지어 대규모 프로젝트에서는 수천 개의 모듈이 존재합니다. 이러한 상황에서 자바스크립트 기반의 도구는 성능 병목 현상이 발생되었고, 종종 개발 서버를 가동하는 데 비합리적으로 오랜 시간을 기다려야 한다거나 HMR을 사용하더라도 변경된 파일이 적용될 때까지 수 초 이상 소요되곤 했습니다. 이와 같은 느린 피드백 루프는 개발자의 생산성에 큰 영향을 줄 수 있습니다. 💡HMR 브라우저를 새로..