scripts-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Scripts Audit

脚本审计

Purpose

审计目的

Audit

package.json

scripts to:

Classify the package with minimal manifest context
Check whether the script interface fits that package role
Prefer Vite Plus conventions for app-style repos
Enforce stable naming and suffix conventions
Improve composition, CI ergonomics, and performance
Flag misleading, platform-specific, or overgrown scripts

对

package.json

中的脚本进行审计，以实现：

基于最少的清单上下文对包进行分类
检查脚本接口是否符合包的角色定位
针对应用类仓库优先遵循Vite Plus约定
强制执行稳定的命名及后缀规范
优化脚本组合、CI易用性与性能
标记具有误导性、平台特定或过于臃肿的脚本

When to Use This Skill

何时使用该技能

Use when the user asks to:

"Audit my npm scripts"
"Standardize package.json script names"
"Decide whether this should be
```
dev
```
or
```
start
```
"
"Review build, check, or release scripts"
"Make root workspace scripts consistent with package scripts"

Trigger phrases: "scripts audit", "package.json scripts", "npm scripts", "pnpm scripts", "bun scripts", "script naming", "script conventions"

当用户提出以下需求时使用：

"审计我的npm脚本"
"标准化package.json的脚本名称"
"判断应该用
```
dev
```
还是
```
start
```
"
"审核build、check或release脚本"
"使根工作区脚本与包脚本保持一致"

触发短语："scripts audit"、"package.json scripts"、"npm scripts"、"pnpm scripts"、"bun scripts"、"script naming"、"script conventions"

Scope

审计范围

This is still a scripts skill, not a full

package.json

audit.

Read adjacent manifest fields only when they change what "good scripts" means:

```
private
```
```
packageManager
```
```
workspaces
```
```
type
```
```
bin
```
```
exports
```
```
files
```
```
engines
```

Do not drift into dependency hygiene,

exports

peerDependencies

, publish metadata, or security scanning unless the user explicitly asks for that broader audit.

这仍是一项仅针对脚本的技能，并非完整的

package.json

审计。

仅当以下清单字段会影响“优质脚本”的定义时，才会读取这些字段：

```
private
```
```
packageManager
```
```
workspaces
```
```
type
```
```
bin
```
```
exports
```
```
files
```
```
engines
```

除非用户明确要求进行更广泛的审计，否则请勿涉及依赖管理、

exports

、

peerDependencies

、发布元数据或安全扫描等内容。

Vite Plus First

优先遵循Vite Plus规范

If a repo uses

vite-plus

, aliases

vite

@voidzero-dev/vite-plus-core

, or invokes

vp

in scripts, treat Vite Plus as the primary app workflow.

Prefer VP-native guidance:

```
build
```
:
```
vp run clean && tsgo && vp build
```
```
check
```
:
```
vp check && vp run typecheck
```
```
test
```
:
```
vp test --run
```
```
test:ci
```
:
```
vp test --run --coverage
```
```
prepare
```
:
```
vp config
```

Do not recommend ESLint-specific patterns in this skill. If the repo exposes Biome explicitly, it is fine to mention

biome

scripts as optional non-VP companion scripts, but VP remains the primary app workflow.

如果仓库使用

vite-plus

、将

vite

别名指向

@voidzero-dev/vite-plus-core

，或在脚本中调用

vp

，则将Vite Plus作为主要的应用工作流。

优先采用VP原生指导方案：

```
build
```
:
```
vp run clean && tsgo && vp build
```
```
check
```
:
```
vp check && vp run typecheck
```
```
test
```
:
```
vp test --run
```
```
test:ci
```
:
```
vp test --run --coverage
```
```
prepare
```
:
```
vp config
```

本技能中不推荐ESLint特定的模式。如果仓库明确使用Biome，可以将

biome

脚本作为可选的非VP配套脚本提及，但VP仍为主要应用工作流。

Non-VP Patterns

非VP模式

Non-VP patterns are still worth mentioning when the repo actually uses them:

Plain
```
pnpm
```
script composition is the normal baseline for monorepo roots, publishable libraries, and release flows.
```
biome
```
scripts are a valid non-VP quality layer, especially in libraries, CLIs, and repos with explicit lint or format commands.
```
prepare: "husky"
```
is a valid non-VP setup pattern when the repo manages git hooks explicitly.

When VP is detected, do not try to "improve" the repo by replacing VP-native app flows with separate non-VP app scripts unless the user explicitly asks for that direction.

当仓库实际使用非VP模式时，这些模式仍值得关注：

纯
```
pnpm
```
脚本组合是单体仓库根目录、可发布库及发布流程的常规基准方案。
```
biome
```
脚本是有效的非VP质量保障层，尤其适用于库、CLI及明确包含lint或format命令的仓库。
当仓库明确管理git钩子时，
```
prepare: "husky"
```
是一种有效的非VP设置模式。

当检测到VP时，请勿尝试用独立的非VP应用脚本替换VP原生应用工作流来“优化”仓库，除非用户明确要求这样做。

Workflow

审计流程

Step 1: Load Minimal Manifest Context

步骤1：加载最少的清单上下文

Read

scripts

plus only the manifest fields that affect script expectations:

bash

jq '{
  name,
  private,
  packageManager,
  type,
  workspaces,
  bin,
  exports,
  files,
  engines,
  scripts
}' package.json

Only inspect

dependencies

devDependencies

when they explain a script choice, for example:

vite-plus

vite

aliased to

@voidzero-dev/vite-plus-core

tsgo

react

-> Vite Plus app expectations

```
storybook
```
,
```
next
```
-> non-VP app expectations
```
typescript
```
->
```
typecheck
```
```
biome
```
,
```
prettier
```
,
```
husky
```
-> non-VP quality/setup expectations
```
vitest
```
,
```
jest
```
,
```
bun:test
```
-> test naming expectations when the repo is not VP-driven

Extract and categorize scripts by purpose:

Runtime:
```
dev
```
,
```
start
```
,
```
preview
```

Quality:

typecheck

lint

lint:*

format

format:*

check

check:*

Build:
```
build
```
,
```
build:*
```
,
```
clean
```
Test:
```
test
```
,
```
test:*
```
,
```
coverage
```
Release:
```
prepack
```
,
```
prepublishOnly
```
,
```
release:*
```

读取

scripts

以及仅会影响脚本预期的清单字段：

bash

jq '{
  name,
  private,
  packageManager,
  type,
  workspaces,
  bin,
  exports,
  files,
  engines,
  scripts
}' package.json

仅当

dependencies

或

devDependencies

能解释脚本选择时，才会检查这些依赖，例如：

```
vite-plus
```
、
```
vite
```
别名指向
```
@voidzero-dev/vite-plus-core
```
、
```
tsgo
```
、
```
react
```
→ 符合Vite Plus应用预期
```
storybook
```
、
```
next
```
→ 符合非VP应用预期
```
typescript
```
→ 需要
```
typecheck
```
脚本
```
biome
```
、
```
prettier
```
、
```
husky
```
→ 符合非VP质量保障/设置预期
```
vitest
```
、
```
jest
```
、
```
bun:test
```
→ 当仓库非VP驱动时的测试命名预期

按用途提取并分类脚本：

运行时：
```
dev
```
、
```
start
```
、
```
preview
```

质量保障：

typecheck

、

lint

、

lint:*

、

format

、

format:*

、

check

、

check:*

构建：
```
build
```
、
```
build:*
```
、
```
clean
```
测试：
```
test
```
、
```
test:*
```
、
```
coverage
```
发布：
```
prepack
```
、
```
prepublishOnly
```
、
```
release:*
```

Step 2: Classify Package Role

步骤2：分类包的角色

Use minimal manifest signals to decide what a sensible script surface looks like.

Role	Typical signals	Script expectations
App	`private: true` , frontend/dev tooling, `vite-plus` , `vp` , `tsgo` , `dev` or `build`	Prefer VP-native `build` , `check` , `test` , `test:ci` , `prepare` ; `dev` is recommended, `preview` is optional
Monorepo root	`workspaces` , `pnpm --filter` , `turbo` , `nx`	Root scripts should mostly delegate and mirror leaf package names
Publishable library	`exports` , `files` , `bin` , not private	`build` , `typecheck` , `lint` , `format:check` , `test` , `prepublishOnly` , optional `size` or `release:dry`
Service / bot / CLI	`start` script, runtime entrypoint, maybe private	`start` , `check` , `test` ; `build` is optional if runtime executes source directly

If the package is ambiguous, say so and audit against the closest role instead of inventing missing requirements.

利用最少的清单信号来确定合理的脚本界面。

角色	典型信号	脚本预期
应用	`private: true` 、前端/开发工具、 `vite-plus` 、 `vp` 、 `tsgo` 、 `dev` 或 `build` 脚本	优先采用VP原生的 `build` 、 `check` 、 `test` 、 `test:ci` 、 `prepare` ；推荐使用 `dev` ， `preview` 为可选
单体仓库根目录	`workspaces` 、 `pnpm --filter` 、 `turbo` 、 `nx`	根目录脚本应主要委托执行并镜像子包的脚本名称
可发布库	`exports` 、 `files` 、 `bin` 、非私有	需要 `build` 、 `typecheck` 、 `lint` 、 `format:check` 、 `test` 、 `prepublishOnly` ；可选 `size` 或 `release:dry`
服务/机器人/CLI	`start` 脚本、运行时入口、可能为私有	需要 `start` 、 `check` 、 `test` ；如果运行时可直接执行源码，则 `build` 为可选

如果包的角色不明确，请明确说明，并参照最接近的角色进行审计，而非凭空添加缺失的要求。

Step 3: Check Whether the Public Script Interface Fits the Role

步骤3：检查公共脚本接口是否符合角色定位

Do not demand the same scripts from every package.

不要要求所有包都使用相同的脚本。

App

应用类

Healthy default surface:

json

{
  "dev": "vp dev",
  "build": "vp run clean && tsgo && vp build",
  "clean": "rm -rf dist coverage reports",
  "check": "vp check && vp run typecheck",
  "typecheck": "tsgo --noEmit",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

If the repo is VP-driven, separate

lint

lint:fix

format

, and

format:check

scripts are optional. Keep them only when they expose distinct Biome behavior the team actually uses.

健康的默认脚本集合：

json

{
  "dev": "vp dev",
  "build": "vp run clean && tsgo && vp build",
  "clean": "rm -rf dist coverage reports",
  "check": "vp check && vp run typecheck",
  "typecheck": "tsgo --noEmit",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

如果仓库由VP驱动，单独的

lint

、

lint:fix

、

format

和

format:check

脚本为可选。仅当团队实际使用这些脚本来展示Biome的独特功能时，才保留它们。

Monorepo root

单体仓库根目录

Root scripts should preserve the same public contract as the main package they expose:

json

{
  "build": "pnpm --filter @edloidas/example run build",
  "check": "pnpm --filter @edloidas/example run check",
  "test": "pnpm --filter @edloidas/example run test",
  "test:ci": "pnpm --filter @edloidas/example run test:ci",
  "dev": "pnpm --filter @edloidas/example exec vp dev"
}

Prefer delegation over re-implementing leaf commands in the root package.

根目录脚本应与它所暴露的主包保持相同的公共约定：

json

{
  "build": "pnpm --filter @edloidas/example run build",
  "check": "pnpm --filter @edloidas/example run check",
  "test": "pnpm --filter @edloidas/example run test",
  "test:ci": "pnpm --filter @edloidas/example run test:ci",
  "dev": "pnpm --filter @edloidas/example exec vp dev"
}

优先采用委托执行，而非在根目录包中重新实现子包的命令。

Publishable library

可发布库

Healthy default surface:

json

{
  "build": "pnpm clean && pnpm build:*",
  "clean": "rm -rf dist coverage",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "format:check": "biome format .",
  "test": "vitest run",
  "validate": "pnpm check && pnpm build && pnpm test:ci",
  "prepublishOnly": "pnpm validate"
}

健康的默认脚本集合：

json

{
  "build": "pnpm clean && pnpm build:*",
  "clean": "rm -rf dist coverage",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "format:check": "biome format .",
  "test": "vitest run",
  "validate": "pnpm check && pnpm build && pnpm test:ci",
  "prepublishOnly": "pnpm validate"
}

Service / bot / CLI

服务/机器人/CLI

Healthy default surface:

json

{
  "start": "bun src/index.ts",
  "check": "bun run typecheck && bun run lint && bun run format:check",
  "test": "bun test"
}

build

is optional here if the runtime already executes the source directly.

健康的默认脚本集合：

json

{
  "start": "bun src/index.ts",
  "check": "bun run typecheck && bun run lint && bun run format:check",
  "test": "bun test"
}

如果运行时可直接执行源码，则此处的

build

为可选。

Step 4: Check Naming Conventions

步骤4：检查命名约定

Prefer a small stable vocabulary of public script names:

Script	Meaning
`dev`	Interactive local development server
`start`	Runtime entrypoint for an app, service, or CLI
`build`	Production or distributable build
`clean`	Remove generated artifacts
`typecheck`	Static type checking only
`lint`	Non-mutating lint pass
`lint:fix`	Lint pass with writes
`format`	Formatter with writes
`format:check`	Formatter verification only
`test`	Default test run
`test:watch`	Interactive watch mode
`test:ci`	Deterministic CI-oriented test run
`coverage`	Coverage-focused test run
`check`	Fast preflight quality gate
`check:fix`	Mutating version of the quality gate
`preview`	Preview built output
`validate`	Slower release gate
`release:dry`	Dry-run publish or release path

Naming rules:

Prefer one canonical name per concern. Flag synonyms such as
```
serve
```
plus
```
dev
```
, or
```
verify
```
plus
```
check
```
, unless they are clearly different tasks.

Prefer

action:target:variant

, for example

build:ui:css

typecheck:node

```
:fix
```
means mutating,
```
:check
```
means verification-only,
```
:watch
```
means interactive,
```
:ci
```
means deterministic strict mode, and
```
:dry
```
means no side effects.
Root scripts should keep the same public names as leaf scripts when delegating.
Use
```
dev
```
for long-running local development workflows. Use
```
start
```
for the runtime entrypoint of a service, bot, or CLI.
In VP repos,
```
check
```
is the primary quality command. Separate
```
lint
```
or
```
format
```
scripts are optional, not mandatory.
In non-VP repos, explicit
```
lint
```
,
```
format
```
, and
```
format:check
```
scripts are normal and worth keeping clear.

优先使用一套小型且稳定的公共脚本名称词汇：

脚本	含义
`dev`	交互式本地开发服务器
`start`	应用、服务或CLI的运行时入口
`build`	生产环境或可分发版本构建
`clean`	删除生成的产物
`typecheck`	仅静态类型检查
`lint`	非修改型lint检查
`lint:fix`	可修改代码的lint检查
`format`	可修改代码的格式化
`format:check`	仅格式化验证
`test`	默认测试运行
`test:watch`	交互式监听模式
`test:ci`	面向CI的确定性测试运行
`coverage`	聚焦覆盖率的测试运行
`check`	快速预检查质量关卡
`check:fix`	可修改代码的质量关卡
`preview`	预览构建产物
`validate`	较慢的发布关卡
`release:dry`	发布或流程的干运行

命名规则：

每个关注点优先使用一个标准名称。标记同义词，例如
```
serve
```
和
```
dev
```
、
```
verify
```
和
```
check
```
，除非它们是明显不同的任务。

优先采用

action:target:variant

格式，例如

build:ui:css

或

typecheck:node

。

```
:fix
```
表示可修改代码，
```
:check
```
表示仅验证，
```
:watch
```
表示交互式，
```
:ci
```
表示确定性严格模式，
```
:dry
```
表示无副作用。
根目录脚本在委托执行时应与子包脚本保持相同的公共名称。
长期运行的本地开发工作流使用
```
dev
```
。服务、机器人或CLI的运行时入口使用
```
start
```
。
在VP仓库中，
```
check
```
是主要的质量保障命令。单独的
```
lint
```
或
```
format
```
脚本为可选，而非强制要求。
在非VP仓库中，明确的
```
lint
```
、
```
format
```
和
```
format:check
```
脚本是常规操作，值得保持清晰。

Step 5: Check Composition

步骤5：检查脚本组合

Leaf scripts should do one job well. Composite scripts should compose those leaf scripts instead of duplicating raw command strings everywhere.

Good composition:

json

{
  "clean": "rm -rf dist coverage reports",
  "typecheck": "tsgo --noEmit",
  "build": "vp run clean && tsgo && vp build",
  "check": "vp check && vp run typecheck",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

Guidelines:

```
check
```
should be the fast, repeatable preflight gate.
```
check:fix
```
should touch the same surfaces as
```
check
```
, but with writes enabled where appropriate.

validate

should be the slower gate, usually

check && build && test

check && build && test:ci

```
prepublishOnly
```
should usually call
```
validate
```
or
```
release:dry
```
rather than inventing a separate release path.
Prefer calling scripts from composite scripts. Avoid copying the same raw command string into multiple places.

Move script logic into

scripts/

files when the command becomes hard to review:

shell conditionals or loops
multiple
```
node -e
```
or
```
bun -e
```
snippets
cross-platform branching
long inline smoke tests or packaging logic

子脚本应专注完成单一任务。组合脚本应调用这些子脚本，而非在各处重复原始命令字符串。

良好的组合示例：

json

{
  "clean": "rm -rf dist coverage reports",
  "typecheck": "tsgo --noEmit",
  "build": "vp run clean && tsgo && vp build",
  "check": "vp check && vp run typecheck",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

指导原则：

```
check
```
应为快速、可重复的预检查关卡。
```
check:fix
```
应覆盖与
```
check
```
相同的范围，但在适当情况下启用代码修改。

validate

应为较慢的关卡，通常是

check && build && test

或

check && build && test:ci

。

```
prepublishOnly
```
通常应调用
```
validate
```
或
```
release:dry
```
，而非单独创建发布流程。
组合脚本优先调用其他脚本。避免在多个地方复制相同的原始命令字符串。

当命令难以审阅时，将脚本逻辑移至

scripts/

目录下的文件中：

shell条件语句或循环
多个
```
node -e
```
或
```
bun -e
```
代码片段
跨平台分支逻辑
冗长的内联冒烟测试或打包逻辑

Step 6: Check Consistency and Performance

步骤6：检查一致性与性能

Look for consistency across related variants:

检查相关变体之间的一致性：

Vite Plus mode pairing

Vite Plus模式配对

jsonc

// Good
"check": "vp check && vp run typecheck",
"test": "vp test --run",
"test:ci": "vp test --run --coverage"

If a VP repo exposes

test:ci

, it should usually add something CI-specific such as coverage or stricter reporting rather than duplicating

test

jsonc

// 良好示例
"check": "vp check && vp run typecheck",
"test": "vp test --run",
"test:ci": "vp test --run --coverage"

如果VP仓库暴露

test:ci

，通常应添加CI特定的内容，例如覆盖率或更严格的报告，而非重复

test

的内容。

Biome pairing

Biome模式配对

jsonc

"lint": "biome check .",
"lint:fix": "biome check --write .",
"format": "biome format --write .",
"format:check": "biome format ."

If the repo keeps Biome scripts, related variants should usually target the same scope unless the difference is intentional and documented.

jsonc

"lint": "biome check .",
"lint:fix": "biome check --write .",
"format": "biome format --write .",
"format:check": "biome format ."

如果仓库保留Biome脚本，相关变体通常应针对相同的范围，除非差异是有意为之且有文档说明。

Runtime consistency

运行时一致性

Within one package, prefer one script runner style unless there is a real reason to mix:

```
pnpm run ...
```
```
bun run ...
```
```
npm run ...
```

If the scripts depend on package-manager-specific features such as

pnpm --filter

pnpm /^build:.*/

, or Bun-only runtime behavior, call out missing or stale

packageManager

metadata because it affects script usability and reproducibility.

在单个包中，优先使用一种脚本运行器风格，除非有合理的理由混合使用：

```
pnpm run ...
```
```
bun run ...
```
```
npm run ...
```

如果脚本依赖包管理器特定的功能，例如

pnpm --filter

、

pnpm /^build:.*/

或仅Bun支持的运行时行为，请指出缺失或过时的

packageManager

元数据，因为这会影响脚本的可用性和可复现性。

Parallelization

并行化

When sub-builds are independent, consider runner-native fan-out:

jsonc

// Sequential
"build": "pnpm build:lib && pnpm build:css"

// Better when independent
"build:ui": "pnpm --color /^build:ui:.*$/"

Parallelize only when it preserves readable output and does not break dependency order.

当子构建任务相互独立时，考虑使用运行器原生的并行执行：

jsonc

// 串行执行
"build": "pnpm build:lib && pnpm build:css"

// 独立任务时更优的方式
"build:ui": "pnpm --color /^build:ui:.*$/"

仅当并行执行能保持输出可读性且不破坏依赖顺序时，才进行并行化。

Step 7: Check Lifecycle Hook Usage

步骤7：检查生命周期钩子的使用

Use package lifecycle hooks for real lifecycle boundaries:

json

{
  "prepare": "vp config",
  "prepack": "pnpm build",
  "prepublishOnly": "pnpm validate"
}

Guidelines:

In VP repos,
```
prepare: "vp config"
```
is a strong default.
In non-VP repos,
```
prepare: "husky"
```
is a valid setup hook when the project manages git hooks explicitly.
```
prepare
```
is for local setup such as VP configuration or git hooks, not for hidden build work.
```
prepack
```
is for ensuring distributable artifacts exist before packing.
```
prepublishOnly
```
is for the final release gate.
Avoid
```
postinstall
```
build steps unless the package truly requires them.

将包生命周期钩子用于真实的生命周期边界：

json

{
  "prepare": "vp config",
  "prepack": "pnpm build",
  "prepublishOnly": "pnpm validate"
}

指导原则：

在VP仓库中，
```
prepare: "vp config"
```
是一个强有力的默认设置。
在非VP仓库中，当项目明确管理git钩子时，
```
prepare: "husky"
```
是有效的设置钩子。
```
prepare
```
用于本地设置，例如VP配置或git钩子，而非隐藏的构建工作。
```
prepack
```
用于确保打包前存在可分发的产物。
```
prepublishOnly
```
用于最终的发布关卡。
除非包确实需要，否则避免使用
```
postinstall
```
构建步骤。

Step 8: Flag Anti-Patterns

步骤8：标记反模式

Call out these issues explicitly:

Placeholder success scripts such as

test: "exit 0"

prepack: "echo Packaging..."

Platform-specific helpers hidden behind generic names, for example
```
analyze: "open dist/stats.html"
```
. If kept, prefer a more explicit name such as
```
analyze:open
```
.
Root workspace scripts that embed leaf-package implementation instead of delegating.
Missing paired scripts where the workflow expects them, such as
```
format
```
without
```
format:check
```
, or
```
lint
```
without
```
lint:fix
```
when Biome is exposed explicitly.
VP app repos that skip
```
prepare: "vp config"
```
and require manual local setup.
Duplicate aliases that do the same thing without adding clarity.
Very long inline script strings that should live in
```
scripts/
```
.

明确指出以下问题：

占位符成功脚本，例如

test: "exit 0"

或

prepack: "echo Packaging..."

。

使用通用名称隐藏的平台特定辅助脚本，例如
```
analyze: "open dist/stats.html"
```
。如果保留，建议使用更明确的名称，例如
```
analyze:open
```
。
根工作区脚本嵌入子包实现而非委托执行。
工作流预期存在但缺失的配对脚本，例如当明确使用Biome时，有
```
format
```
但无
```
format:check
```
，或有
```
lint
```
但无
```
lint:fix
```
。
跳过
```
prepare: "vp config"
```
并需要手动本地设置的VP应用仓库。
无意义的重复别名，即执行相同操作但未增加清晰度的脚本。
应移至
```
scripts/
```
目录的极长内联脚本字符串。

Step 9: Generate Report

步骤9：生成审计报告

markdown

undefined

markdown

undefined

Scripts Audit Report

脚本审计报告

Package Role

包角色

Monorepo root delegating to
```
@edloidas/example
```

单体仓库根目录，委托执行
```
@edloidas/example
```
的脚本

Naming Issues

命名问题

```
serve
```
duplicates
```
dev
```
without a clearer contract
```
lint:check
```
should be
```
lint
```

```
serve
```
与
```
dev
```
重复，且未提供更清晰的约定
```
lint:check
```
应改为
```
lint
```

Composition Issues

组合问题

prepublishOnly

duplicates

check && build && test

; reuse

validate

Root
```
build
```
re-implements leaf build steps instead of delegating

prepublishOnly

重复了

check && build && test

的逻辑；应复用

validate

脚本

根目录
```
build
```
脚本重新实现了子包的构建步骤，而非委托执行

Lifecycle Issues

生命周期问题

```
prepare
```
runs a build; move that work to
```
build
```
or
```
prepack
```

```
prepare
```
执行了构建工作；应将该工作移至
```
build
```
或
```
prepack
```

Performance / Consistency Issues

性能/一致性问题

```
lint
```
and
```
lint:fix
```
target different file sets
```
test:ci
```
duplicates
```
test
```
instead of adding coverage or stricter CI behavior

```
lint
```
和
```
lint:fix
```
针对不同的文件集合
```
test:ci
```
重复了
```
test
```
的内容，未添加覆盖率或更严格的CI行为

Recommendations

建议

Standardize on
```
build
```
,
```
check
```
,
```
test
```
,
```
test:ci
```
, and
```
prepare
```
as the public VP surface, with
```
dev
```
when the repo exposes it.
Rename scripts to follow
```
action:target:variant
```
.
Introduce
```
validate
```
and let
```
prepublishOnly
```
call it.
Move long inline smoke-test logic into
```
scripts/
```
.

undefined

标准化使用
```
build
```
、
```
check
```
、
```
test
```
、
```
test:ci
```
和
```
prepare
```
作为VP的公共脚本集合，仓库暴露
```
dev
```
时也应包含该脚本。
按照
```
action:target:variant
```
格式重命名脚本。
引入
```
validate
```
脚本，并让
```
prepublishOnly
```
调用它。
将冗长的内联冒烟测试逻辑移至
```
scripts/
```
目录。

undefined

Common Patterns

常见模式

Use these as pattern families, not a single universal template. VP app repos should prefer the VP example. Libraries, CLIs, and monorepo roots often use the non-VP

pnpm

or Bun patterns below.

将这些作为模式家族使用，而非单一的通用模板。VP应用仓库应优先采用VP示例。库、CLI和单体仓库根目录通常使用以下非VP的

pnpm

或Bun模式。

Vite Plus App

Vite Plus 应用

json

{
  "dev": "vp dev",
  "build": "vp run clean && tsgo && vp build",
  "clean": "rm -rf dist coverage reports",
  "typecheck": "tsgo --noEmit",
  "check": "vp check && vp run typecheck",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

Optional Biome companion scripts:

json

{
  "lint": "biome check .",
  "lint:fix": "biome check --write .",
  "format": "biome format --write .",
  "format:check": "biome format ."
}

json

{
  "dev": "vp dev",
  "build": "vp run clean && tsgo && vp build",
  "clean": "rm -rf dist coverage reports",
  "typecheck": "tsgo --noEmit",
  "check": "vp check && vp run typecheck",
  "test": "vp test --run",
  "test:ci": "vp test --run --coverage",
  "prepare": "vp config"
}

可选的Biome配套脚本：

json

{
  "lint": "biome check .",
  "lint:fix": "biome check --write .",
  "format": "biome format --write .",
  "format:check": "biome format ."
}

Monorepo Root (pnpm)

单体仓库根目录（pnpm）

json

{
  "build": "pnpm --filter @edloidas/example run build",
  "check": "pnpm --filter @edloidas/example run check",
  "test": "pnpm --filter @edloidas/example run test",
  "test:ci": "pnpm --filter @edloidas/example run test:ci",
  "dev": "pnpm --filter @edloidas/example exec vp dev",
  "prepare": "pnpm --filter @edloidas/example run prepare"
}

json

{
  "build": "pnpm --filter @edloidas/example run build",
  "check": "pnpm --filter @edloidas/example run check",
  "test": "pnpm --filter @edloidas/example run test",
  "test:ci": "pnpm --filter @edloidas/example run test:ci",
  "dev": "pnpm --filter @edloidas/example exec vp dev",
  "prepare": "pnpm --filter @edloidas/example run prepare"
}

Non-VP Publishable Library

非VP可发布库

json

{
  "clean": "rm -rf dist coverage",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "lint:fix": "biome lint --write .",
  "format": "biome format --write .",
  "format:check": "biome format .",
  "check": "pnpm typecheck && pnpm lint && pnpm format:check",
  "check:fix": "pnpm typecheck && pnpm lint:fix && pnpm format",
  "build": "pnpm clean && pnpm build:*",
  "test": "vitest run",
  "test:watch": "vitest",
  "test:ci": "vitest run --coverage",
  "validate": "pnpm check && pnpm build && pnpm test:ci",
  "release:dry": "pnpm publish --dry-run --no-git-checks",
  "prepublishOnly": "pnpm validate"
}

json

{
  "clean": "rm -rf dist coverage",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "lint:fix": "biome lint --write .",
  "format": "biome format --write .",
  "format:check": "biome format .",
  "check": "pnpm typecheck && pnpm lint && pnpm format:check",
  "check:fix": "pnpm typecheck && pnpm lint:fix && pnpm format",
  "build": "pnpm clean && pnpm build:*",
  "test": "vitest run",
  "test:watch": "vitest",
  "test:ci": "vitest run --coverage",
  "validate": "pnpm check && pnpm build && pnpm test:ci",
  "release:dry": "pnpm publish --dry-run --no-git-checks",
  "prepublishOnly": "pnpm validate"
}

Non-VP Service / CLI

非VP服务/CLI

json

{
  "start": "bun src/index.ts",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "lint:fix": "biome lint --write .",
  "format": "biome format --write .",
  "format:check": "biome format .",
  "check": "bun run typecheck && bun run lint && bun run format:check",
  "check:fix": "bun run typecheck && bun run lint:fix && bun run format",
  "test": "bun test",
  "test:watch": "bun test --watch",
  "validate": "bun run check && bun run test"
}

json

{
  "start": "bun src/index.ts",
  "typecheck": "tsc --noEmit",
  "lint": "biome lint .",
  "lint:fix": "biome lint --write .",
  "format": "biome format --write .",
  "format:check": "biome format .",
  "check": "bun run typecheck && bun run lint && bun run format:check",
  "check:fix": "bun run typecheck && bun run lint:fix && bun run format",
  "test": "bun test",
  "test:watch": "bun test --watch",
  "validate": "bun run check && bun run test"
}