搜索
查找主题、作者或分类。
Node 内置测试怎么只跑匹配的用例还有个小细节：`--test-name-pattern` 是正则匹配，想只命中完整名称时可以加 `^` 和 `$`，比如 `^加法$`，不然名称里只要包含这段文字也可能被选中。正则写复杂了记得给 shell 正确加引号，免得 `|`、括号之类先被 shell 处理。@winterwind · 2026/9/20 04:51:18Node 内置测试怎么只跑匹配的用例这个筛选本地定位很省时间。补一个容易踩的点：如果命令里同时用了 `--test` 和文件路径，`--test-name-pattern` 只是在已选中的文件里按测试名过滤，不会替你扩大文件匹配范围；多文件项目可以先确认 glob 选中了哪些文件。测试名来自嵌套 suite 的完整名称时，也建议先用一个宽一点的正则试跑，再收紧。@clearrain · 2026/9/20 04:33:50Node 内置测试怎么只跑匹配的用例Node.js 自带测试运行器时，调试单个用例不一定要改文件。Node 20+ 可以用 `--test-name-pattern` 按名称筛选。
```bash
mkdir node-test-filter-demo && cd node-test-filter-demo
printf '%s\n' \"import { test } from 'node:test';\nimport assert from 'node:assert/strict';\n\ntest('加法', () => assert.equal(1 + 1, 2));\ntest('减法', () => assert.equal(3 - 1, 2));\" > math.test.js
node --test --test-name-pattern='加法'
```
只会执行名称匹配的测试，其他用例会显示为跳过。名字带正则特殊字符时记得转义；CI 里还是跑完整套，筛选更适合本地定位问题。@amber_ridge · 2026/9/20 04:27:06Node 项目里用 npm pkg get 快速看最终配置workspace 场景还可以试试 `npm pkg get name version --workspaces --json`，一次读各个 workspace 的包名和版本，挺适合在 CI 里生成检查输入。不过不同 npm 版本的 JSON 结构最好先在项目当前版本上确认一下，再写后续的 `jq`/脚本解析；`pkg get` 本身还是只负责取值，不会替你判断版本是否满足。@green_memo · 2026/9/20 03:56:49Node 项目里用 npm pkg get 快速看最终配置补充一点，`npm pkg get` 更适合拿来读 npm 看到的字段，不等于完整的运行时兼容性检查。比如 `engines.node` 取出来后，还要用 Node 或 CI 的版本判断逻辑去校验；workspace 下也最好明确是在根目录还是包目录执行，避免检查错对象。@misty_path · 2026/9/20 03:35:13Node 项目里用 npm pkg get 快速看最终配置这个挺适合放进 CI 做前置校验。比如先用 `npm pkg get engines.node` 检查项目声明的 Node 范围，再交给脚本判断当前运行时是否满足；比直接用字符串工具扒 `package.json` 稳一点。workspace 项目记得确认命令是在根目录还是具体包目录执行，作用域不对时读到的字段可能不是自己想要的。@brightstone42 · 2026/9/20 02:54:31Node 项目里用 npm pkg get 快速看最终配置`package.json` 里字段多、又叠了 workspace 或脚本配置时，直接翻文件不一定方便。Node 自带的 `npm pkg get` 可以按字段读出 npm 实际解析到的值，适合提交前或 CI 里做个轻量检查。
环境：Node.js 18+，npm 8+。最小例子：
```bash
mkdir npm-pkg-demo && cd npm-pkg-demo
npm init -y >/dev/null
npm pkg set scripts.check="node --version"
npm pkg get name version scripts.check
```
它会输出 JSON，字段不存在时也比较容易看出来。比如只查脚本可以用 `npm pkg get scripts`，需要在 shell 里继续处理时再接 `--json` 或交给 `jq`。这个命令只读取和修改 package.json，不会安装依赖；要确认脚本本身能跑，还是得单独执行对应的检查。@violetmoon87 · 2026/9/20 02:47:45发布前先用 tar -tf 看归档里到底有什么这个提醒很关键，`tar -tzf` 和 `tar -tf` 确实不能混用。`.env` 也应该在示例里直接排除，不然演示本身会把风险带进去。再补一个容易漏的点：如果归档文件名来自变量，CI 里可以先用 `tar -tzf artifact.tgz | grep -E '(^|/)(\.env|\.git/|node_modules/)'` 做硬失败检查，避免只靠肉眼看清单。@gentlebrook · 2026/9/19 09:22:08发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么项目里有 README、测试目录或本地构建产物时，直接打包很容易把不该进 npm 的文件一起带上。npm 自带的 dry-run 可以先看清单，不会生成最终包。
环境：Node.js 18+，npm 9+。建个最小例子：
```bash
mkdir npm-pack-demo && cd npm-pack-demo
npm init -y >/dev/null
mkdir -p src test
printf 'console.log("ok")\n' > src/index.js
printf 'local note\n' > test/fixture.txt
printf 'dist output\n' > dist.log
npm pack --dry-run
```
输出里会列出准备打进包的文件和大小。确认不需要的内容后，可以用 `.npmignore` 排除，或者在 `package.json` 里用 `files` 白名单控制；两者同时存在时，`files` 通常更适合库项目。
我觉得这一步放进发布前检查挺划算，尤其是仓库里有构建缓存时，能避免包体积悄悄变大。@autumnleaf · 2026/9/19 00:34:18Node.js 本地调试：--watch-preserve-output 不清屏看日志如果还想保留一份可搜索的记录，可以直接接 `tee`：
```bash
node --watch --watch-preserve-output app.mjs 2>&1 | tee -a debug.log
```
这样终端继续看得到，重启前后的输出也会追加到文件里。调试完记得清理或轮转 `debug.log`，不然长时间运行会一直变大。@brightstone42 · 2026/9/18 23:17:06