nodejs-cli-best-practices

分类: 开发与编程 | 上传者: lirantal | 下载: 0 | 版本: v1.0（最新）

根据 37 个既定最佳实践指导和审核 Node.js CLI 应用程序开发，涵盖用户体验、分发、互操作性、可访问性、测试、错误处理、开发设置、分析、版本控制和安全性。在构建、扩展、审查或搭建 Node.js CLI 时，包括当有人说“审核我的 CLI”、“审查我的 CLI 代码”、“我正在构建 CLI 工具”，或询问添加参数解析、错误处理、颜色输出、STDIN、--json 标志、退出代码、--version 标志或 npm 发布时，请使用此技能。即使没有明确提及最佳实践也适用。还会触发“我应该如何在 CLI 中实现 X”或“在 Node.js CLI 中执行 Y 的正确方法是什么”。请勿用于没有 CLI 入口点的 Node.js 后端或 API 开发。

更新日志: Source: GitHub https://github.com/lirantal/nodejs-cli-apps-best-practices

目录结构

当前层级: tree/main/skills/nodejs-cli-best-practices/

📁 evals/
- 📁 fixtures/
  - 📄 bad-cli-clean.js 2.4 KB
  - 📄 bad-cli.js 4.3 KB
  - 📄 bad-package.json 593 B
- 📄 evals.json 7.0 KB
- 📄 README.md 6.0 KB
📁 references/
- 📄 best-practices.md 14.4 KB
📄 EVALS.md 6.7 KB
📄 SKILL.md 7.7 KB
📄 tile.json 995 B

SKILL.md

---
name: nodejs-cli-best-practices
description: Guide and audit Node.js CLI application development against 37 established best practices covering UX, distribution, interoperability, accessibility, testing, error handling, development setup, analytics, versioning, and security. Use this skill when building, extending, reviewing, or scaffolding a Node.js CLI — including when someone says "audit my CLI", "review my CLI code", "I'm building a CLI tool", or asks about adding argument parsing, error handling, color output, STDIN, --json flags, exit codes, --version flags, or npm publishing. Applies even when best practices are not explicitly mentioned. Also trigger for "how should I implement X in my CLI" or "what's the right way to do Y in a Node.js CLI". Do NOT use for Node.js backend or API development with no CLI entry point.
metadata:
  version: 1.0.0
  category: nodejs
  tags: [nodejs, cli, best-practices, audit, command-line]
---

This skill operates in two modes — **audit** for reviewing existing CLI code and **development guide** for building new features or tools.

## Critical

Always read `references/best-practices.md` before producing any output. It contains the complete reference for all 37 practices with code examples and recommended packages. It is the source of truth for both modes — do not rely on general knowledge alone, as several practices (specific package recommendations, §X.X numbering, configuration precedence order) are specific to this guide.

## Determining the mode

| Trigger | Mode | Action |
|---------|------|--------|
| User provides existing CLI code or files to review | **Audit** | Produce a structured audit report |
| User asks how to build or implement something | **Development guide** | Surface relevant practices with examples |
| User says "review and help me improve" | **Both** | Audit first, then provide concrete guidance for each failing practice |

---

## Audit mode

Systematically compare the provided code against the practices in `references/best-practices.md`. Focus on what is verifiable from the code. Use judgment to mark practices as not applicable (➖) when there's genuinely no way to assess them from static analysis (e.g., Docker support when the project shows no distribution intent).

**Prioritize by user impact** — a missing exit code (§6.4) or absent `--version` flag (§9.1) affects every user and every CI pipeline; missing Docker image (§4.1) is low priority for most projects.

### Audit report format

```
## Node.js CLI Best Practices Audit

### Summary
✅ N practices followed  ⚠️ N need attention  ❌ N not implemented  ➖ N not applicable

---

### 1. Command Line Experience
| # | Practice | Status | Finding |
|---|----------|--------|---------|
| 1.1 | Respect POSIX args | ✅ | Uses yargs with proper short/long aliases |
| 1.2 | Build empathic CLIs | ❌ | No interactive fallback when required args absent |
...

[Repeat for each section with applicable practices]

---

### Priority recommendations

**High priority** (user-facing or CI-breaking):
- **§6.4 Exit codes** — `process.exit()` called without a code
  ```js
  // Fix
  process.exit(1); // on error
  process.exit(0); // on success
  ```

**Medium priority**:
- ...

**Low priority / nice to have**:
- ...
```

Keep findings concise and tied to specific code patterns. Always include a concrete fix with code for each ❌.

---

## Development guide mode

When building a new CLI feature or tool, don't wait to be asked — surface relevant best practices immediately based on what the user is building.

**For a "building a CLI from scratch" request**, organize guidance by development phase:

1. **Project setup** (§7.1, §7.3, §4.4, §2.2): bin object, shebang, files field, shrinkwrap
2. **Argument design** (§1.1, §1.2, §1.7, §3.4): POSIX compliance, empathic fallbacks, zero-config, config precedence
3. **I/O and interoperability** (§3.1, §3.2, §4.2): STDIN, structured output, graceful degradation
4. **Error handling** (§6.1–§6.5): trackable codes, actionable messages, debug mode, exit codes
5. **UX polish** (§1.4, §1.5, §1.6): colors, rich interactions, hyperlinks
6. **Versioning** (§9.1–§9.7): `--version` flag, semver, changelog
7. **Security** (§10.1): argument injection

**For a targeted feature request** (e.g., "add error handling", "add a --json flag"), surface only the directly relevant practices.

### Development guidance format

```
## Node.js CLI best practices for [feature/topic]

### Checklist
- [ ] §X.Y Practice name — one-line explanation of why it matters

### Implementation
[Concrete, copy-pasteable code]

### Recommended packages
- `package-name` — when and why to use it
  npm install package-name

### Common mistakes
- What not to do → why it breaks → what to do instead
```

---

## Quick reference: which section applies

| Topic | Sections |
|-------|----------|
| Argument parsing / flags | §1.1, §1.7, §3.4 |
| Prompts / interactivity | §1.2, §1.5 |
| Colors / styling | §1.4, §4.2 |
| STDIN / piping | §3.1 |
| JSON / structured output | §3.2, §4.2 |
| Cross-platform issues | §3.3, §7.2 |
| Error messages | §6.1, §6.2 |
| Exit codes | §6.4 |
| Debug / verbose mode | §6.3 |
| `--version` flag | §9.1, §9.3 |
| package.json setup | §7.1, §7.3, §9.3 |
| npm publishing / distribution | §2.1, §2.2, §9.6 |
| Security / user input | §10.1 |
| Configuration persistence | §1.3, §2.3 |
| Node.js version targeting | §4.3 |
| Analytics / telemetry | §8.1 |

---

## Examples

### Example 1: Audit mode

**User says:** "Audit my Node.js CLI against best practices. Here's my entry file and package.json."

**Actions:**
1. Read `references/best-practices.md`
2. Examine the provided files against each applicable practice
3. Produce the structured audit report with per-section table and priority recommendations

---

### Example 2: Development guide mode (new CLI from scratch)

**User says:** "I'm building a Node.js CLI that parses log files and outputs a summary table. It needs to work cross-platform and I want to publish it on npm."

**Actions:**
1. Read `references/best-practices.md`
2. Identify all practices relevant to this CLI type (cross-platform, npm-published, table output)
3. Organize guidance by development phase (project setup → argument design → I/O → errors → UX → versioning → security)

---

### Example 3: Development guide mode (targeted feature)

**User says:** "My CLI is crashing and just dumping stack traces. How do I add proper error handling?"

**Actions:**
1. Read `references/best-practices.md` sections §6.1–§6.5
2. Surface only the directly relevant practices
3. Provide a concrete, copy-pasteable error handling wrapper

---

## Common mistakes to avoid

| Mistake | Why it matters | Correct approach |
|---------|---------------|------------------|
| Marking §4.1 (Docker) as ❌ for a small personal CLI | Docker is rarely needed; not applicable is honest | Use ➖ when the practice genuinely doesn't fit the project's scope |
| Only auditing the entry file, ignoring package.json | Several high-impact violations (§7.1, §7.3, §2.1, §4.3) live in package.json | Always audit both the entry file and package.json when both are provided |
| Recommending `package-lock.json` for §2.2 | The practice specifically calls for `npm-shrinkwrap.json` for published CLIs | Reference `references/best-practices.md` for the exact requirement |
| Skipping the priority grouping in audit reports | Users need to know what to fix first, not just what's wrong | Always include High / Medium / Low priority sections with concrete fixes |
| Providing a development guide without code examples | Prose guidance alone is not actionable | Every recommended practice should include at least one copy-pasteable code block |

登录后下载/点赞/收藏 ❤ 4K | ★ 0

nodejs-cli-best-practices

目录结构

SKILL.md

举报内容

提示