Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow disabling watcher altogether #14189

Closed
4 tasks done
sheremet-va opened this issue Aug 24, 2023 · 1 comment · Fixed by #14208
Closed
4 tasks done

Allow disabling watcher altogether #14189

sheremet-va opened this issue Aug 24, 2023 · 1 comment · Fixed by #14208

Comments

@sheremet-va
Copy link
Member

Description

When calling createServer, vite always starts a watcher however it is not always necessary if the consumer just wants to use transformRequest API. For example, when running Vitest with --run or --no-watch command we don't need a watcher and currently set ignored to ['**/*'] to lower the memory consumption. But it seems that it's not enough because Vite adds new files to watch manually (like tsconfig).

Suggested solution

Allow passing down false as an option to server.watch:

import { defineConfig } from 'vite'
export default defineConfig({
  server: {
    watch: false
  }
})

Instead of starting a chokidar service, Vite will create a noop watcher to not break the API.

Alternative

No response

Additional context

No response

Validations

@AriPerkkio
Copy link
Contributor

AriPerkkio commented Aug 24, 2023

While working on vitest-dev/vitest#3925 I noticed that sometimes Chokidar can prevent Vitest process from exiting gracefully. By using why-is-node-running to debug the process, it pointed to Vite's Chokidar usage:

# fsevents
node:internal/async_hooks:202                                                                                                          
/Users/x/y/vitest/node_modules/.pnpm/fsevents@2.3.2/node_modules/fsevents/fsevents.js:31                                            - let instance = Native.start(Native.global, path, since, handler);
file:///Users/x/y/vitest/node_modules/.pnpm/vite@4.3.9_@types+node@18.7.13/node_modules/vite/dist/node/chunks/dep-e8f070e8.js:51089
file:///Users/x/y/vitest/node_modules/.pnpm/vite@4.3.9_@types+node@18.7.13/node_modules/vite/dist/node/chunks/dep-e8f070e8.js:51145
file:///Users/x/y/vitest/node_modules/.pnpm/vite@4.3.9_@types+node@18.7.13/node_modules/vite/dist/node/chunks/dep-e8f070e8.js:51348
file:///Users/x/y/vitest/node_modules/.pnpm/vite@4.3.9_@types+node@18.7.13/node_modules/vite/dist/node/chunks/dep-e8f070e8.js:51424
file:///Users/x/y/vitest/node_modules/.pnpm/vite@4.3.9_@types+node@18.7.13/node_modules/vite/dist/node/chunks/dep-e8f070e8.js:51513
node:internal/process/task_queues:95                                                                                                   

When the process was hanging and required forceful exit, it would leave a zombie process on the background. This process started to eat memory really fast and eventually caused out-of-memory from Node's side. This process is shown on the video below.

chokidarvitest.mp4

After patching Vite by modifying node_modules/ directly with following changes, the process hangs disappeared immediately and background zombie processes were gone.

+    const watcher =  { close: () => {}, on: () => { return watcher }, add: () => {} }
-    const watcher = chokidar.watch(
-    // config file dependencies and env file might be outside of root
-    [root, ...config.configFileDependencies, config.envDir], resolvedWatchOptions);

const watcher = chokidar.watch(
// config file dependencies and env file might be outside of root
[root, ...config.configFileDependencies, config.envDir],
resolvedWatchOptions,
) as FSWatcher

AriPerkkio added a commit to AriPerkkio/vite that referenced this issue Aug 27, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Oct 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants