Description

Vite dev server producing unexpected hmr updates on startup without changes. Chokidar is throttling directory reads on initial watch, producing add events, and vite responds with hmr updates to the add events. Deduping the array passed to chokidar.watch on server creation fixes the issue.

Additional context

We noticed during the startup process of the vite dev server with our project that it would regularly and seemingly randomly produce hmr update logs, even though no changes were being made during the startup process. What was discovered was that chokidar was throttling directory reads during the initial watch on vite server creation. Throttled events from chokidar result in add events emitted even with ignoreInitial set to true. Vite listens for these add events and triggers an hmr update for the associated file.

The throttling is occurring, because the files/directories passed to chokidar.watch could and in our case did contain duplicate directories. chokidar does not appear to dedupe the array passed to it, so chokidar ended up duplicatively reading the same directories via _handleRead. It appears the intention of the throttling within _handleRead is to catch changes that may have occurred during the initial watch process. So, chokidar treated the duplicative reads as throttled changes (i.e. initialAdd as false and emits an add event), which informed vite, and vite responded with an hmr update.

The default configuration of vite appears to encounter this, which is where we hit it. As our root option was process.cwd() and envDir was defaulting to root. So, chokidar.watch receives the root directory twice via root and config.envDir.

This PR uses a Set to remove any duplicate strings from the array of files/directories passed to chokidar.watch to avoid this problem (i.e. remove the duplicate config.envDir entry).

The workaround for this ahead of this change is to not have root and config.envDir share the same value (i.e. set config.envDir to a different directory).

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines, especially the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.