Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#904 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
55/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
build-system

调研方向

Read crates/vt/src/session/cache/archive.rs around lines 56–65 and crates/vt/src/session/cache/mod.rs around lines 589–600 to follow cache restoration; then inspect collect_glob_paths in crates/vt/src/session/execute/cache_update.rs. The issue proposes an opt-in replace flag for object-form output entries that removes matching files missing from the archive before unpacking. Done means replacement entries restore exact matching outputs while entries without the flag and { auto: true } keep current behavior; the payload names no tests.

由索引模型根据 Issue 内容生成。

描述

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 #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.

主要语言
Rust
星标
480
派生
50
平均合并
1 天 5 小时
30 天内合并 PR
63

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

voidzero-dev/vite-task 的其他 Issue

查看 voidzero-dev/vite-task 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。