Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

A task input for its package's locked dependencies, so a lockfile edit misses only the tasks whose dependencies moved

オープン
  • 何か問題がありますか？
#876 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust, yaml
領域
build-system, tooling

調査の方向性

Start with the cache input handling and lockfile parsing paths; the issue does not name source files or tests, so locate those entry points first. Read the existing input documentation and inspect how task fingerprints are built, then trace how workspace lockfile entries represent transitive, peer-qualified, optional, and workspace dependencies. Done means a declared input hashes only the task package's resolved dependency closure and fails when a required lockfile entry is missing.

索引モデルが issue の本文から書いたものです。

説明

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

Summary

A cached task cannot say "I depend on my package's installed dependencies" in a way that is both correct and stable. Each setting available today either replays a stale result or misses for a change the task never depended on.

This asks for one more input kind: a hash of the task's own package's resolved dependency closure, read from the lockfile. Turborepo has the same thing as each task's external_deps_hash.

What happens today

Two packages. a depends on is-odd through the catalog, and b depends on left-pad.

# pnpm-workspace.yaml
packages:
  - packages/*
catalog:
  is-odd: 3.0.1

// packages/a/package.json
{ "name": "a", "type": "module", "dependencies": { "is-odd": "catalog:" } }
// packages/b/package.json
{ "name": "b", "type": "module", "dependencies": { "left-pad": "1.3.0" } }

// packages/a/build.mjs
import isOdd from 'is-odd';
console.log('a built', isOdd(3));

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

export default defineConfig({
  run: {
    tasks: {
      build: { command: 'node build.mjs', cache: { input: INPUT } },
      check: { command: 'vp lint build.mjs', cache: { input: [{ auto: true }] } },
    },
  },
});

Each run below starts from a warm cache, then makes one change and runs vp install (vp 1.3.0, pnpm 10.18.0, macOS):

INPUT Change Result
[{ auto: true }], the default vp install --force, which changes nothing check: cache miss: 'node_modules/.modules.yaml' modified
[{ auto: true }, '!node_modules/**'], the docs' example catalog is-odd: 3.0.1 → 2.0.0 build: cache hit, replaying output built against is-odd 3.0.1
the docs' example plus { pattern: 'pnpm-lock.yaml', base: 'workspace' } b's left-pad 1.3.0 → 1.2.0 build: cache miss: 'pnpm-lock.yaml' modified
  • Default: tracking is exact for a plain script: build replays after b's bump and misses after a's. But any command that loads a config reads pnpm's install metadata, so it misses after every reinstall (voidzero-dev/vite-plus#2845).
  • Excluding node_modules: this takes dependencies out of the key entirely. A task's fingerprint is its cwd, program, args and envs (SpawnFingerprint), with no dependency component.
  • Naming the lockfile: this puts dependencies back, but as one file for the whole workspace. Every task that names it misses on every lockfile edit.

In our monorepo (138 packages), build-like tasks use the third setting. Over one week, 2,011 of the 4,673 misses whose reason was pnpm-lock.yaml (43%) were for packages whose resolved dependencies had not changed.

Proposal

A declared input whose content is the task's package's resolved dependency closure. Shape and name are yours to pick; for example:

cache: { input: [{ auto: true }, '!node_modules/**', { dependencies: 'locked' }] }

The closure is what the package's lockfile entry reaches:

  • each dependency's specifier and resolved version;
  • transitively, every resolved package those reach, including peer-qualified variants and optional dependencies;
  • workspace dependencies, followed through their own lockfile entries;
  • the catalog, override and patch entries that reach any of them.

With that input, b's bump replays a's build and the catalog bump misses it. A lockfile entry the closure needs but cannot find should fail the run, not silently hash less.

Prior art
  • Turborepo adds external_deps_hash to each task's hash (turborepo-hash). It computes the value from per-package closures (all_transitive_closures) for npm, pnpm, Yarn and Bun lockfiles.
  • Nx hashes the versions of the external packages a project's source imports, and its externalDependencies input adds the tools a command runs (docs).
How we work around it

We built this outside Vite Task:

  1. A pnpm-lock.yaml parser computes each package's closure by the rules above.
  2. A root task writes one hash file per package.
  3. Each task depends on that root task and declares its own package's hash file as an input.

It works, but every consumer needs an extra dependency edge, and every workspace that wants this has to re-implement the lockfile's semantics. We're happy to share the closure rules, or to open a PR if you want this approach.

主要言語
Rust
スター
480
フォーク
50
平均マージ
1日 3時間
マージ済み PR（30日）
62

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

voidzero-dev/vite-task のほかの issue

voidzero-dev/vite-task の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。