grace's dev_note

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

MSW 사용 방법 MSW 설치하기 npm install msw --save-dev # or yarn add msw --dev 먼저 MSW 패키지를 설치합니다. 패키지를 설치하고 나면 프로젝트에 MSW를 세팅합니다. Service Worker를 제공하기 위해 사용하고자 하는 프로젝트의 directory를 지정해서 실행해줍니다. npx msw init ./public --save 다음을 실행하고나면 public 디렉토리에 service worker가 만들어지고 package.json에 다음과 같이 표시됩니다 { "name": "your-app", "msw": { "workerDirectory": "public" } } Define Mocks 이제 Mocking 할 API를 핸들링할 핸들러를 만들어주어야 합니..

MSW MSW(Mock Service Worker)는 API Mocking 라이브러리로, 서버향의 네트워크 요청을 가로채서 모의 응답을 보내주는 역할을 합니다. 따라서, MSW 라이브러리를 통하면 Mock 서버를 구축하지 않아도 네트워크 수준에서 Mocking 할 수 있습니다. MSW가 이러한 역할을 할 수 있는 이유는 Service Worker를 통해 HTTP 요청을 가로채기 때문입니다. Service Worker가 뭐에요? Service Worker는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나입니다. Service Worker 덕분에 애플리케이션의 UI Block 없이 연산을 처리할 수 있습니다. 이러한 특징으로 인해, Service Worke..

전체 개발 프로세스 중 요구 사항 분석 및 기획, 백엔드 개발, 프론트엔드 개발에 이르는 각각의 개발 과정은 크게 겹치지 않고 진행되는 것이 가장 이상적입니다. 왜냐하면, 개발 과정에서 도출되는 요구 사항이나 사용 가능한 인터페이스에 변경이 있으면 각 단계별 의존성에 따라 다시 작업해야 하는 경우가 발생하기 때문입니다. 따라서, 개발 과정이 다음과 같이만 진행된다면 요구 사항과 제공된 스펙에 따라 순조롭게 프론트엔드 개발을 진행할 수 있습니다. 하지만 현실적으로 프론트엔드와 백엔드가 병행하여 개발하게 되는 경우가 많습니다. 이때 프론트엔드에서 백엔드의 API를 활용해야 하는 것처럼, 백엔드 개발에 종속적인 부분이 있다면, 해당 부분이 완성되기 전까지는 프론트엔드 개발을 진행할 수가 없고 그 부분이 진행된..

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 브라우저를 새로..

React에는 애플리케이션 내의 잠재적인 문제를 알아내기 위한 도구가 있습니다. 바로 StrictMode입니다. 개발 모드에서 앱 내의 잠재적인 버그를 알아내기 위해서 컴포넌트를 두 번 렌더해줍니다. 당연하게도, 개발 모드에서만 활성되기 때문에 프로덕션 빌드(배포)에는 영향을 끼치지 않습니다. React나 Next.js 앱을 시작하면 next.config.js 파일이 있는 것을 확인할 수 있습니다. 해당 파일에 들어가보면 /** @type {import('next').NextConfig} */ const nextConfig = { reactStrictMode: true, } module.exports = nextConfig 이렇게 작성되어 있는 것을 확인할 수 있는데요. 여기에서 stric..