Vite의 환경변수 사용법

1️⃣ 왜 vite를 사용해야 하는가?

1. esm지원 이전, 소스 모듈을 브라우저에서 실행할 수 있는 파일로 변경하는 번들링이라는 작업을 수행했다. → webpack을 통해 번들링 하면 index.js라는 파일 하나로 만들어 지는 것을 알 것이다.
2. JavaScript 모듈의 개수도 극적으로 증가하는 요즘, JavaScript 기반의 도구는 성능 병목 현상이 발생 되었다.

Rollup을 이용한 번들링.

1. webpack과 다르게 코드들을 동일한 수준으로 호이스팅 한 후 한 번에 번들링을 진행하기 때문에 속도에서는 webpack보다 빠르고 결과물도 훨씬 가볍다. → 번들링 속도와 용량에 이점
2. es 모듈 형태로 빌드를 할 수 있어 라이브러리나 패키지를 작업하는데 활용할 수 있다. webpack은 es 모듈로 번들을 할 수 없음, 오직 commonJS 형태로 번들링 진행 가능 → 번들링 된 파일의 효율성 증가

HMR의 사용성

1. HMR을 사용하더라도 변경된 파일이 적용될 때 까지 수 초 이상 소요되곤 했습니다. 이와 같은 느린 피드백 루프는 개발자의 생산성과 행복에 적지 않은 영향을 줄 수 있습니다.
2. vite는 HMR을 지원합니다. 이는 번들러가 아닌 ESM을 이용하는 것입니다. 어떤 모듈이 수정되면 vite는 그저 수정된 모듈과 관련된 부분만을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐입니다. 전 과정에서 완벽하게 ESM을 이용하기에, 앱 사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않습니다.

→ 이전까지 HMR은 Hot Module Reloading의 줄임말로 알고 있었다. vite에서는 공식적으로 이를 Hot Module Replacement라고 명명하고 있었다. 기존의 HMR은 변경점이 생기면 부분적으로 교체하는 것이 아닌, 말 그대로 reload하는 과정을 거치고 있었는데, vite에서는 변경이 일어난 모듈만 부분적으로 replace하는, 즉 고교체하는 작업으로 이루어진다. 실제로 CRA을 사용하다가 Vite를 사용하면서 훨씬 HMR의 사용성이 정말 정말 좋았다.

❗️이번에 발생한 문제점, Vite환경 변수에 대해 알아보게 된 계기

1. react-router 배포시 404페이지가 나타나는 에러가 발생. 이유에 대해서 찾았고, basename을 지정해주면 해결 된다는 글을 읽음.
2. 새롭게 사용해보는 createBrowserRouter예시

import * as React from "react";
import * as ReactDOM from "react-dom/client";
import {
  createBrowserRouter,
  RouterProvider,
} from "react-router-dom";
import "./index.css";

const router = createBrowserRouter([
  {
    path: "/",
    element: <div>Hello world!</div>,
  },
], {basename : "/"}); // basename을 작성해줌으로써 해결됨.

ReactDOM.createRoot(document.getElementById("root")).render(
  <React.StrictMode>
    <RouterProvider router={router} />
  </React.StrictMode>
);

1. 하지만 basename에 / 이 값이 항상 base일린 없다.vite에서 baseurl을 지정하는 방법은 아래와 같이 사용하면 된다는 것을 알았다.

const router = createBrowserRouter([
  {
    path: "/",
    element: <div>Hello world!</div>,
  },
], { basename: import.meta.env.BASE_URL });

그래서 추가적으로 어떤 환경변수를 사용하면 되는지 알기 위해서 정리해보았다!

2️⃣ 환경변수

1. import.meta.env.MODE: {string} 현재 앱이 동작하고 있는 모드입니다.
2. import.meta.env.BASE_URL:  {string} 앱이 제공되는 베이스 URL이며, 이 값은 base 설정에 의해 결정됩니다. https://ko.vitejs.dev/config/shared-options.html#base
3. import.meta.env.PROD: {boolean} 앱이 프로덕션에서 실행 중인지 여부입니다(개발 서버 실행 혹은 프로덕션 빌드 시 NODE_ENV='production'로 설정).
4. import.meta.env.DEV: {boolean} 앱이 개발 환경에서 실행 중인지 여부이며, 항상 import.meta.env.PROD와 반대되는 값을 가집니다.
5. import.meta.env.SSR: {boolean} 앱이 서버에서 실행 중인지 여부입니다.

.env 파일

1. .env의 변수들은 기본적으로 문자열로 파싱된다. 이를 환경변수 파싱 이라고 합니다.

.env                # 모든 상황에서 사용될 환경 변수
.env.local          # 모든 상황에서 사용되나, 로컬 개발 환경에서만 사용될(Git에 의해 무시될) 환경 변수
.env.[mode]         # 특정 모드에서만 사용될 환경 변수
.env.[mode].local   # 특정 모드에서만 사용되나, 로컬 개발 환경에서만 사용될(Git에 의해 무시될) 환경 변수

1. dev 명령으로 실행되는 개발 서버는 development 모드로 동작하고, build 명령으로 실행되는 경우에는 production 모드로 동작
2. 즉 vite build 명령을 실행하게 되면 .env.production에 정의된 환경 변수를 불러오게 됩니다.
3. staging모드로 실행하고 싶다면?

   # .env.staging
   VITE_APP_TITLE=My App (staging)
   

   import.meta.env.MODE === staggin // true
   

4. vite build --mode staging
5. 특정 모드에 대한 환경 변수는 일반적인 환경 변수(.env)보다 높은 우선순위를 갖습니다.
6. Vite에서 접근 가능한 환경 변수는 일반 환경 변수와 구분을 위해 VITE_ 라는 접두사를 붙여 나타냅니다. VITE_SOME_KEY=123
7. 타입 설정은 다음과 같다. (src/vite-env.d.ts 파일이 기본적으로 제공된다.

// src/vite-env.d.ts
/// <reference types="vite/client" />

interface ImportMetaEnv {
  readonly VITE_APP_TITLE: string;
  readonly VITE_123: string;
  // 다른 환경 변수들에 대한 타입 정의...
}

 

Vite