viteplus

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

VitePlus

Use this skill to move a frontend repo closer to the stock VitePlus toolchain without blindly deleting repo-specific release or runtime logic.

使用此技能可将前端仓库向标准VitePlus工具链迁移，同时不会盲目删除仓库特有的发布或运行时逻辑。

Migration Targets

迁移目标

When a repo is adopting VitePlus, default to this destination unless a repo-specific boundary clearly blocks it:

CI uses

voidzero-dev/setup-vp@v1

, then runs

vp env

vp install

vp check

, and

vp test

test files use
```
vite-plus/test
```
when VitePlus owns the test surface
scripts prefer
```
vp test
```
,
```
vp test --watch
```
,
```
vp test --coverage
```
,
```
vp pack
```
,
```
vp build
```
, and
```
vp run <script>
```
over direct package-manager, raw Vitest, or tsdown wiring
hooks prefer
```
vp staged
```
/ Vite config wiring instead of custom Husky or
```
lint-staged
```
setup
contributor docs use the new
```
vp
```
commands in the same change
if you keep the old command shape, explain the repo-specific reason explicitly

当仓库采用VitePlus时，默认以此为目标，除非仓库特有的限制明确阻碍该目标的实现：

CI使用

voidzero-dev/setup-vp@v1

，随后执行

vp env

、

vp install

、

vp check

和

vp test

当VitePlus负责测试层面时，测试文件使用
```
vite-plus/test
```
脚本优先使用
```
vp test
```
、
```
vp test --watch
```
、
```
vp test --coverage
```
、
```
vp pack
```
、
```
vp build
```
和
```
vp run <script>
```
，而非直接调用包管理器、原生Vitest或tsdown配置
钩子优先使用
```
vp staged
```
/ Vite配置，而非自定义Husky或
```
lint-staged
```
设置
贡献者文档在同一变更中使用新的
```
vp
```
命令
如果保留旧命令格式，需明确说明仓库特有的原因

Workflow

工作流程

Audit the repo's current scripts, workflows, Vite config, test imports, release flow, package manager, and any repo-specific packaging steps.
Read references/bootstrap.md first for migration entrypoints, local guidance-file discovery such as
```
AGENTS.md
```
,
```
CLAUDE.md
```
, or repo rules, and the standard validation path.
Choose the repo shape: read references/packages.md for standalone packages or references/monorepos.md for workspaces.
Update the local tool surface together: scripts,
```
vite.config.ts
```
, test imports, hook wiring, and packaging commands should move as one migration instead of drifting piecemeal. After this step, run
```
vp check && vp test
```
to verify the migrated surface is coherent before moving on. If either command fails, resolve the errors before proceeding — do not carry forward a broken tool surface into CI or release changes.
Update CI and release automation with references/ci-cd.md, replacing hand-rolled Node setup with the stock Vite+ flow where it fits.
Update tests and coverage wiring with references/testing.md before changing assertions about test behavior.
Check references/commands.md before changing command invocations, script wiring, or package-manager usage.
Keep repo-specific binary, release, or packaging steps only where Vite+ does not replace them cleanly.
Validate the migrated repo end-to-end by running
```
vp env && vp install && vp check && vp test
```
. Then re-check the key runtime surfaces: build output (verify
```
vp build
```
produces the expected artifacts), test coverage (confirm
```
vp test --coverage
```
reports pass), and hook triggers (confirm
```
vp staged
```
fires correctly on a staged change). If any surface fails, fix it before declaring the migration complete.

Concrete examples:

yaml

- uses: voidzero-dev/setup-vp@v1
- run: vp env
- run: vp install
- run: vp check && vp test

export default defineConfig({
  staged: {
    "*.{js,ts,tsx,vue,svelte}": "vp check --fix",
  },
})

Before/after for a common migration — replacing hand-rolled test scripts:

diff

 # package.json scripts
-- "test": "vitest run --coverage",
-- "test:watch": "vitest",
+- "test": "vp test",
+- "test:watch": "vp test --watch",

审核仓库当前的脚本、工作流、Vite配置、测试导入、发布流程、包管理器以及任何仓库特有的打包步骤。
首先阅读references/bootstrap.md，获取迁移入口点、本地指引文件（如
```
AGENTS.md
```
、
```
CLAUDE.md
```
）或仓库规则，以及标准验证路径。
选择仓库形态：对于独立包，阅读references/packages.md；对于工作区，阅读references/monorepos.md。
同步更新本地工具层面：脚本、
```
vite.config.ts
```
、测试导入、钩子配置和打包命令应作为一次完整迁移进行，而非零散更新。完成此步骤后，运行
```
vp check && vp test
```
验证迁移后的工具层面是否连贯，再继续下一步。若任一命令失败，需先解决错误，不要将损坏的工具层面带入CI或发布变更中。
使用references/ci-cd.md更新CI和发布自动化，在合适的情况下用标准Vite+流程替换手动搭建的Node环境。
在修改测试行为的断言之前，使用references/testing.md更新测试和覆盖率配置。
在修改命令调用、脚本配置或包管理器使用之前，查看references/commands.md。
仅当Vite+无法完美替代时，才保留仓库特有的二进制文件、发布或打包步骤。
通过运行
```
vp env && vp install && vp check && vp test
```
端到端验证迁移后的仓库。然后重新检查关键运行时层面：构建输出（验证
```
vp build
```
生成预期产物）、测试覆盖率（确认
```
vp test --coverage
```
报告通过）和钩子触发（确认
```
vp staged
```
在暂存变更时正确触发）。若任一层面失败，需修复后再宣告迁移完成。

具体示例：

yaml

- uses: voidzero-dev/setup-vp@v1
- run: vp env
- run: vp install
- run: vp check && vp test

export default defineConfig({
  staged: {
    "*.{js,ts,tsx,vue,svelte}": "vp check --fix",
  },
})

常见迁移的前后对比——替换手动搭建的测试脚本：

diff

 # package.json scripts
-- "test": "vitest run --coverage",
-- "test:watch": "vitest",
+- "test": "vp test",
+- "test:watch": "vp test --watch",

Guardrails

注意事项

Start from
```
vp create
```
or
```
vp migrate
```
when the repo shape allows it instead of rebuilding the migration by hand.
Do not invent custom Husky, lint-staged, or shell-hook wiring when
```
vp staged
```
/ Vite config already fits the repo.
Keep
```
pack
```
config in
```
vite.config.ts
```
when feasible; do not maintain parallel tsdown config unless the repo has a deliberate reason.
Do not delete repo-specific release workflows, binary packaging, or publish steps just to look more "stock."
When coverage requires
```
@vitest/coverage-v8
```
, treat mixed-version warnings as a known Vite+ caveat and verify whether the same warning reproduces in a fresh stock scaffold before calling it a repo bug.
Update contributor docs when install, test, or verify commands change.

当仓库形态允许时，从
```
vp create
```
或
```
vp migrate
```
开始，而非手动重建迁移流程。
当
```
vp staged
```
/ Vite配置已适配仓库时，不要自定义Husky、lint-staged或shell钩子配置。
尽可能将
```
pack
```
配置保留在
```
vite.config.ts
```
中；除非仓库有明确理由，否则不要维护并行的tsdown配置。
不要仅仅为了更“标准化”而删除仓库特有的发布工作流、二进制打包或发布步骤。
当覆盖率需要
```
@vitest/coverage-v8
```
时，将混合版本警告视为已知的Vite+ caveat，并在将其认定为仓库bug之前，验证该警告是否会在全新的标准脚手架中重现。
当安装、测试或验证命令发生变化时，更新贡献者文档。