@moontern-labs/code-budget

中文文档
0.1.3发布于 2026/11/02MITTypeScriptES Module

Enforce explicit maintenance-size budgets for source repositories

原始使用文档
文档目录6 节
  1. Configuration
  2. Tooling defaults
  3. Move an existing configuration to tooling
  4. Commands
  5. Named ceilings
  6. Library API

@moontern-labs/code-budget

An explicit implementation-LOC ceiling with unlimited tooling and verification.

npm install --save-dev @moontern-labs/[email protected]
npx code-budget                 # infer and explain when unconfigured
npx code-budget init --scope simple-tool
npx code-budget                 # enforce the committed configuration

For a patch release, npm run bump increments x.x.N to x.x.(N + 1) and updates the lockfile and versioned source/documentation references. Preview it with npm run bump -- --dry-run.

Implementation measures product code. Tooling measures development, build, release, lint, and operational support separately, without a ceiling. Tests, test-only helpers, and fixtures are also measured but never limited. Documentation, lockfiles, licenses, and package metadata are reported separately. Moving source into an unmatched directory or overlapping areas fails a configured check.

Configuration

import { defineConfig } from "@moontern-labs/code-budget";

export default defineConfig({
  scope: "platform",
  areas: [
    {
      name: "runtime",
      kind: "implementation",
      include: ["src/**", "bin/**"],
      exclude: ["**/*.test.*", "**/__tests__/**"],
    },
    {
      name: "tooling",
      kind: "tooling",
      include: ["scripts/**"],
      exclude: ["scripts/test/**", "**/*.test.*"],
    },
    {
      name: "tests",
      kind: "verification",
      include: ["test/**", "tests/**", "**/*.test.*", "**/__tests__/**"],
      exclude: ["**/fixtures/**"],
    },
    {
      name: "fixtures",
      kind: "verification",
      include: ["**/fixtures/**"],
    },
    {
      name: "generated-engine",
      kind: "excluded",
      include: ["engine/generated/**"],
      reason: "Reproduced from the checksum-pinned upstream source archive.",
    },
  ],
});

Tooling defaults

Inference and init use the same classifications:

PathsClassification
Everything under .github/**, including tests and templatestooling
Root scripts/**, tools/**, and tooling/**tooling, except recognized tests and fixtures
Root .husky/**tooling, except recognized tests and fixtures
src/**, lib/**, app/**, packages/**, and bin/**implementation, except recognized tooling, tests, and fixtures
Directories named test, tests, spec, specs, or __tests__; files matching *.test.* or *.spec.*verification, outside .github/**
Directories named fixture, fixtures, or __fixtures__verification, outside .github/**

Tool configuration patterns match at any depth. Supported NAME.config.EXT files use these names: code-budget, vite, vitest, webpack, rollup, esbuild, tsup, babel, eslint, prettier, jest, playwright, cypress, next, nuxt, svelte, astro, postcss, and tailwind. Supported extensions are js, cjs, mjs, ts, cts, mts, and json.

Other tooling patterns cover tsconfig*.json; .eslintrc, .prettierrc, and .babelrc, either extensionless or with js, cjs, mjs, json, yaml, or yml; Makefile, GNUmakefile, Justfile, justfile, Rakefile, Dockerfile, and Dockerfile.*; and Compose YAML files named compose, compose.*, docker-compose, or docker-compose.*. Recognized tests and fixtures take precedence over these patterns outside .github/**.

These defaults cannot determine a script's purpose. Add explicit areas for other tool configurations, deployment manifests, or tooling directories. Unknown source-like paths still fail configured checks. Application-specific names such as src/customer.config.ts stay in implementation.

Move an existing configuration to tooling

Upgrading does not rewrite committed configurations or infer a kind from an area's name. Change an existing tooling area's kind from implementation to tooling. Give .github/** its own tooling area, and exclude .github/** from any other matching areas. Use code-budget init --scope <scope> --dry-run to inspect the complete defaults without replacing your policy.

For product logic under a tooling directory, add an implementation area such as include: ["scripts/import-customers/**"]. Add that same pattern to the tooling area's exclude list. Retain separate verification rules for any tests and fixtures in the product directory. Overlapping areas still fail checks.

Reports include TOOLING (UNLIMITED) and JSON totals.tooling, including file, LOC, and language counts. Tooling contributes to the combined language report, but not the implementation ceiling or verification-to-implementation ratio. The JSON envelope remains version 1.0 with the additive tooling total and kind. Consumers that exhaustively handle area kinds must accept tooling.

The standalone config names are code-budget.config.mjs, .js, and .cjs. The 0.0.1 budgets schema remains readable and emits migration diagnostics; its maxFiles and maxBytes limits are legacy-only.

Commands

  • code-budget: inferred non-failing analysis without config; check with it.
  • code-budget report: report configured or inferred measurements, exit 0 for policy excess.
  • code-budget check: require config; exit 1 for violations and 2 for errors.
  • code-budget init --scope <scope>: create config and immediately check it; supports --dry-run and --force.
  • code-budget scopes [--details]: show every ceiling and bundled benchmark.
  • code-budget explain <path>: show matching patterns and enforcement effect.

All commands accept --cwd, --config, --json, --details, --no-color, --version, and contextual --help. JSON writes only a versioned envelope to stdout, including for usage and configuration errors.

Named ceilings

ScopeImplementation LOC
atomic-library1,000
simple-tool10,000
standalone-tool40,000
platform75,000
infrastructure175,000
suite350,000

See METHODOLOGY.md, or run code-budget scopes --details, for the bundled fixed-reference benchmark dataset and counting boundary.

Library API

The package exports analyzeRepository, checkBudgets, defineConfig, config loading and classification helpers, rendering helpers, and SCOPES / SCOPE_NAMES metadata with TypeScript declarations.

版本与发布记录

@moontern-labs/code-budget 共发布 2 个版本,首次发布于 2026/11/02;过去 12 个月发布了 2 个版本。

版本发布日期距今
0.1.3latest2026/11/021 天前
0.0.0-stage2026/11/021 天前

关于 @moontern-labs/code-budget 的常见问题

@moontern-labs/code-budget 是什么?

为源存储库强制执行显式的维护规模预算

如何安装 @moontern-labs/code-budget?

在项目目录运行 npm install @moontern-labs/code-budget,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 code-budget,可以用 npx code-budget 直接运行。

@moontern-labs/code-budget 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@moontern-labs/code-budget 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@moontern-labs/code-budget 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.18.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@moontern-labs/code-budget 可以商用吗?

@moontern-labs/code-budget 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@moontern-labs/code-budget 还在维护吗?

最新版本 0.1.3 发布于 2026/11/02(1 天前);至今共发布 2 个版本,其中过去 12 个月发布了 2 个;首次发布于 2026/11/02。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。