Question 1

Vite 개발 서버에서 server.restart()를 반복적으로 호출할 때 메모리 누수가 발생하는 이유는 무엇이며, 어떻게 해결할 수 있나요?

Accepted Answer

Vite 8.x는 서버의 init/listen 클로저가 options 객체를 계속 참조 가능한 상태로 유지하기 때문에, 매번 `server.restart()` 이후에도 `options.previousEnvironments`를 통해 폐기된 환경과 그 모듈 그래프를 메모리에 유지합니다. 이 문제는 재시작을 거듭할수록 연쇄적으로 누적되어 수백 MB의 힙을 점유할 수 있으며, 결국 Node 힙 고갈을 유발합니다. 수정 방법: `_createServer`(`packages/vite/src/node/server/index.ts`)에서 await된 환경 초기화가 완료된 후 초기화 전용 참조를 해제합니다: `options.previousEnvironments = undefined`. 이 시점에는 이전 인스턴스가 이미 각 환경의 `init`에 전달된 상태이므로 안전합니다. Vite 8.3.0 및 8.1.4에서 Node 22/24/26으로 검증 완료: 폐기된 환경이 8/8 유지에서 0/8으로 감소합니다. 참고로 누수를 완전히 측정하려면 함께 패치해야 하는 별도의 독립적인 유지 버그가 Rolldown(#10887)에 존재합니다.

Question 2

resolve.tsconfigPaths를 활성화한 상태에서 Vite 8 개발 서버에서 발생하는 'Tsconfig not found' 오류를 해결하는 방법

Accepted Answer

이 문제는 Vite의 개발 서버가 어떤 tsconfig `include`와도 일치하지 않는 합성(synthetic) 기본 importer(`<root>/index.html`)를 사용할 때 발생하며, 이로 인해 tsconfig 자동 탐색이 상위 디렉터리의 tsconfig.json까지 올라가게 되고 해당 파일의 `extends`를 해석할 수 없게 됩니다(중첩된 git worktree나 React Router 프레임워크 모드에서 흔히 발생합니다). 해결 방법: Vite 설정에서 최상위 `tsconfig` 옵션을 명시적으로 설정하여 탐색을 프로젝트의 설정 파일로 고정하세요:

```ts
// vite.config.ts
export default defineConfig({
  tsconfig: './tsconfig.json',
  resolve: { tsconfigPaths: true },
})
```

또는 상위 디렉터리의 tsconfig.json을 제거하거나 수정하세요(예: 상위 디렉터리에 누락된 `extends` 패키지인 `@tsconfig/strictest`를 설치). 이 버그는 `vite dev` 및 importer 없이 `transformRequest()`를 호출하는 도구(예: `react-router build`/`react-router dev`)에 영향을 미칩니다.

Question 3

Vite experimental.bundledDev 사용 시 'factory.fn is not a function' 또는 "Cannot read properties of undefined (reading 'exports')" 오류를 해결하는 방법은?

Accepted Answer

버전 불일치 문제입니다: Vite 8.2.4에 번들된 dev 클라이언트는 rolldown 1.2.4의 DevRuntime을 인라인으로 포함하지만, rolldown >= 1.2.6에서 정적 import에 대한 dev 출력 방식이 변경되어 오래된 런타임이 새 출력을 실행할 수 없습니다. 해결 방법: Vite를 8.3.5 이상으로 업그레이드하세요(`npm install vite@^8.3.5`). 그러면 설치된 rolldown에서 DevRuntime을 로드하므로 emitter와 런타임이 동기화 상태를 유지합니다. Vite 8.2.4를 계속 사용해야 하는 경우의 우회 방법: rolldown을 1.2.5로 고정하세요(`npm install rolldown@1.2.5` 또는 package.json에 override 지정). 1.2.5의 출력 방식은 인라인된 런타임과 여전히 일치하기 때문입니다.

Question 4

Yarn 4와 `nodeLinker: pnpm` 사용 시 `yarn install` 후 Vite가 의존성을 다시 번들링하지 않는 문제를 해결하는 방법

Accepted Answer

이 문제는 `nodeLinker: pnpm` 설정의 Yarn 4가 `node_modules/.yarn-state.yml`과 `.pnp.cjs`를 모두 생성하지 않기 때문에 발생합니다. 그 결과 Vite는 빈 lockfile을 해시(`lockfileHash: e3b0c442...`)하고 오래된 사전 번들링된 의존성을 계속 사용하게 됩니다.

임시 해결 방법:

```bash
npx vite --force
```

또는 개발 서버를 시작하기 전에 Vite의 의존성 캐시를 삭제하세요:

```bash
rm -rf node_modules/.vite/deps && npx vite
```

자동화된 해결 방법을 원한다면 `postinstall` 스크립트를 추가할 수 있습니다:

```json
{
  "scripts": {
    "postinstall": "rm -rf node_modules/.vite/deps"
  }
}
```

영구적인 해결 방법: `packages/vite/src/node/optimizer/index.ts`에서 Vite의 `lockfileFormats`를 패치하여, 기존 Yarn 항목 뒤에 소스 lockfile로 폴백하도록 수정합니다:

```ts
{ path: 'yarn.lock', checkPatchesDir: '.yarn/patches', manager: 'yarn' }
```

또는 `fix(optimizer): fall back to yarn.lock for lockfile hash` 변경 사항이 포함된 릴리스로 Vite를 업그레이드하세요.

Question 5

Windows에서 'EBUSY: resource busy or locked, watch' 오류로 Vite 개발 서버가 크래시되는 문제를 해결하는 방법

Accepted Answer

근본 원인: Vite의 개발 서버는 chokidar의 `change`/`add`/`unlink` 이벤트는 구독하지만 `error` 이벤트는 구독하지 않습니다. 따라서 감시자(watcher)에서 발생하는 모든 실패(일시적으로 잠긴 파일로 인한 EBUSY, EPERM, ENOSPC, inotify 한도 소진 등)가 처리되지 않은 예외가 되어 전체 프로세스를 종료시킵니다. Node 24.16.0 이상에서는 libuv 1.52가 감시 대상 파일을 읽기 접근 권한으로 열기 때문에 이 문제가 훨씬 쉽게 발생합니다(일반적인 발생 조건: Vite 루트 안에 ASP.NET `bin/` 폴더가 있고, 방금 컴파일된 DLL이 아직 잠겨 있는 경우). 코어 수정이 배포될 때까지 사용할 수 있는 임시 해결 방법은 다음과 같습니다:

1) `vite.config.js`에 플러그인을 추가하여 직접 에러 핸들러를 연결합니다:
```js
export default {
  plugins: [{
    name: 'watcher-error-guard',
    configureServer(server) {
      server.watcher.on('error', (err) => console.error('Watcher error (ignored):', err))
    }
  }]
}
```

2) 잠긴 빌드 출력물을 제외하여 chokidar가 해당 경로에 `fs.watch()`를 호출하지 않도록 합니다:
```js
export default { server: { watch: { ignored: ['**/bin/**', '**/obj/**'] } } }
```

3) Node를 24.16.0 미만(libuv < 1.52)으로 고정하여 새로 작성되었지만 아직 잠겨 있는 파일로 인한 EBUSY 발생을 방지합니다.

근본적인 수정(Vite가 FSWatcher에 `error` 리스너를 연결하는 방식)은 현재 작업 중이며, 상위 libuv 회귀 문제는 libuv/libuv#5270에서 추적되고 있습니다.

vite

개요

README 미리보기

FAQ (5)

同类型项目

hermes-agent

firecrawl

go

markitdown