cache.output: opt-in exact restore, so a hit removes files the cached run did not write #904

Written by an AI agent (Claude) on behalf of @jasonkuhrt.

Problem

A cache hit unpacks the output archive over the workspace and deletes nothing (archive.rs L56-65, called from restore). For a task whose run replaces a folder, a hit therefore does not leave what a run leaves: a file in that folder that the cached run never wrote survives the hit.

Reproduction on vite-plus 1.4.0:

// vite.config.ts
import { defineConfig } from 'vite-plus';

export default defineConfig({
  run: {
    tasks: {
      generate: {
        command: 'node generate.mjs',
        cache: {
          input: ['generate.mjs', 'names.txt'],
          output: ['generated/**'],
        },
      },
    },
  },
});

// generate.mjs: replaces generated/ whole, one file per name in names.txt
import { mkdirSync, readFileSync, rmSync, writeFileSync } from 'node:fs';

rmSync('generated', { recursive: true, force: true });
mkdirSync('generated');
for (const name of readFileSync('names.txt', 'utf8').split(/\s+/).filter(Boolean)) {
  writeFileSync(`generated/${name}.ts`, `export const ${name} = 1;\n`);
}

$ echo 'a b' > names.txt
$ vp run generate
$ node generate.mjs
$ ls generated
a.ts  b.ts

$ echo 'export const c = 1;' > generated/c.ts    # a file an earlier run left
$ vp run generate
$ node generate.mjs ◉ cache hit, replaying
$ ls generated
a.ts  b.ts  c.ts                                  # c.ts survives the hit

$ vp run --no-cache generate
$ node generate.mjs ⊘ cache disabled
$ ls generated
a.ts  b.ts                                        # a run removes it

In practice c.ts comes from the checkout's own earlier run: a commit removes or renames something the task generates a file for, the checkout pulls it, and the remote cache already holds the run for the new commit. We hit this with a Prisma client generator: a removed scalar's file outlived the restore, and type checking failed with TS2307 on its now-missing import.

Why the runner can't infer it

The disk plus the archive can't tell a leftover from a file the task means to keep. If the command writes one file per name and deletes nothing, a run also leaves c.ts, and today's merge matches that run. Only the config author knows that a run replaces the folder.

Proposal

An opt-in on the object form of an output entry:

cache: {
  output: [{ pattern: 'generated/**', replace: true }],
},

On a hit, before unpacking, the restore matches the entry's pattern against the disk with the same collect_glob_paths that builds the archive, negative globs included, and deletes the matches the archive lacks. Entries without replace, and { auto: true }, keep today's behavior.

• With fix(cache): leave outputs that already match untouched when restoring a cache hit #901 (leave outputs that already match untouched), a replace hit becomes an exact sync: matching files untouched, changed files rewritten, leftovers removed.
• Docs: a replace entry owns every file its pattern matches. Two tasks whose replace patterns overlap would delete each other's files on a hit.
• The name replace is a suggestion.

The workaround available today, an uncached task that deletes the outputs before the cached one runs, makes every output file disappear for as long as the restore takes, so another task of the same run or an editor reading them in that window sees them missing.