vite icon indicating copy to clipboard operation
vite copied to clipboard

Add `.jj` directory to the default ignored list for file watcher

Open fiadliel opened this issue 7 months ago • 1 comments

Description

I would like for the .jj directory to be included in the default ignored list for the watcher (in the vite config) when running the dev server.

Reasoning:

jj VCS aims to be a mostly git-compatible system that I'm sure many people use with vite (but I'm not sure about exact statistics for its use). It stores its state in a .jj directory under the root of the repository.

The first issue here is that this is a potentially large directory which adds significantly to the watch burden.

Secondly, it supports a "co-located store" option, where it stores a copy of the checked out git repository in .jj/repo/store/git - which does not match the default .git ignore pattern.

Thirdly, jj eagerly updates its state when possible. This includes the ability to set up its own file watcher, which looks for updates to the currently checked out files (minus files in .gitignore), and snapshots them in the state. This could (with badly configured gitignore) cause a loop of both watchers wanting to update their state. The impact of reloads can also extend to servers which are referenced by the open page during constant reloads.

The developers of code using vite may not even be aware that their users are using jj (to add to the ignored list in config). And it's not obvious to users of jj that their use of jj could be an issue.

So I suggest that this makes it a good candidate for the default ignored list in the configuration. It's actually more vital to keep .jj out of the ignored list than .git, because of the eager state update. The main argument against is a question of how popular jj is (I certainly think it's a viable alternative to git for most use, and a lot of people like it).

Suggested solution

In resolveChokidarOptions, the ignored list could be expanded:

  const ignored: WatchOptions['ignored'] = [
    '**/.git/**',
    '**/.jj/**',
    '**/node_modules/**',
    '**/test-results/**', // Playwright
    escapePath(cacheDir) + '/**',
    ...arraify(ignoredList || []),
  ]

There are two other places that are also worth considering:

  • fs.deny for serverConfigDefaults
  • the ignored files under warmup.ts

These are possibly less critical, but not including in fs.deny could expose files accidentally.

Alternative

One could leave it to developers to add to individual projects. This list of projects is almost unbounded, as every project which could be checked out by jj should have this entry added.

Alternatively, the watched files should be a whitelist, not a blacklist. But this is already tracked in other open issues.

Additional context

No response

Validations

fiadliel avatar May 14 '25 08:05 fiadliel

If we do this, apart from .jj we should also include other know directories of VCS to the list (like CVS, .svn, .hg, _darcs, .fossil, and .pijul).

My vote for now is that this should be a vite plugin that configures the project for a different VCS from Git.

patak-dev avatar May 29 '25 13:05 patak-dev

why not '**/.*/**'?

davidglezz avatar Jun 07 '25 17:06 davidglezz

'**/.*/**' is likely too aggressive. There are many frameworks using .xxx as a config location where users would modify files manually such as .vitepress, .storybook.

hi-ogawa avatar Jun 09 '25 00:06 hi-ogawa

We discussed with the team today and decided that it is better for projects using non-git vcs to configure vite to ignore these files (manually or through a plugin).

patak-dev avatar Jun 25 '25 11:06 patak-dev

better for projects using non-git vcs to configure vite to ignore these files

FWIW, jj is a bit of a special case because it is git compatible. So it's not like the project decides to use jj, any contributor can decide to use it and then the change is pushed to the remote git repo as normal. Other users would hardly know jj had been used at all.

And a nit on the OP: By default git is used as a storage for both colocated and not colocated. It's just that in the colocated case the git repo is stored exposed in the project root as .git, to make tooling expecting a normal git repo mostly just work.

algmyr avatar Jun 28 '25 09:06 algmyr