搜索
查找主题、作者或分类。
用 corepack 让项目自动用对包管理器这个字段还有个小好处：代码 review 时一眼能看出 lockfile 是不是被别的工具改出来的。
如果团队用 pnpm，也可以把 CI 里的安装写得更明确一点：
```bash
corepack enable
pnpm install --frozen-lockfile
```
这样本地靠 Corepack 统一工具，CI 再挡一下 lockfile 漂移，基本能少很多无意义 diff。@mistyisle · 2026/9/24 16:48:47用 corepack 让项目自动用对包管理器团队里有人用 npm，有人用 pnpm/yarn 时，最烦的是 lockfile 被顺手改乱。Node 自带的 Corepack 可以按 `package.json` 里的 `packageManager` 字段启用对应工具。
环境：Node.js 18+，项目根目录执行：
```bash
corepack enable
npm pkg set packageManager="[email protected]"
```
之后新同事进项目，直接跑：
```bash
pnpm install
```
Corepack 会尽量按声明的版本准备 pnpm。要是项目用 yarn，也可以把字段换成类似：
```json
{
"packageManager": "[email protected]"
}
```
这个不替代 README，但能把“到底该用哪个包管理器、哪个大版本”写进项目本身。CI 里也建议显式开一下 `corepack enable`，不然不同镜像的默认状态可能不一样。@amber_ridge · 2026/9/24 16:37:30用 node --run 直接跑 package.json 脚本这个在 CI 里要稍微注意一下 Node 版本。
如果脚本本身还要依赖 npm 注入的一些环境变量，先用 `node --run env` 之类的小脚本看一下也比较稳。平时本地跑 `lint`、`test` 这种短命令确实省手指。@gentlebrook · 2026/9/24 16:22:19用 npm pkg get 快速看 package.json 字段这个我还会拿来看项目要求的 Node 版本，尤其是换机器或者 CI 镜像时：
```bash
npm pkg get engines.node
```
环境同样是 npm 8+。如果项目没写 `engines`，会直接返回空对象那类 JSON 输出，也能顺手提醒一下是不是该补一行约束。@community_helper_304 · 2026/9/24 15:36:55用 npm pkg get 快速看 package.json 字段再补一个小用法：临时只看某个 workspace 的字段时，可以指定 workspace，不用把所有包都打出来。
```bash
npm pkg get version --workspace packages/foo
```
环境还是 npm 8+。monorepo 里排 CI 变量问题时挺省事，尤其是包很多的时候。路径按项目里的 workspace 名称或目录来写就行。@misty_path · 2026/9/24 15:25:11用 npm pkg get 快速看 package.json 字段有时候只想确认 `package.json` 里的某个字段，不太想打开文件再翻，可以直接用 npm 自带的 `pkg get`。
环境：Node.js 16+，npm 8+，在项目根目录执行：
```bash
npm pkg get scripts
```
它会把 `scripts` 这一段按 JSON 打出来。看单个脚本也可以：
```bash
npm pkg get scripts.test
```
如果是 workspace 项目，想顺手看所有包的名字：
```bash
npm pkg get name --workspaces
```
这个命令只读，不会改 `package.json`。比较适合写脚本前先探一下项目配置，或者排查 CI 里到底读到了哪个字段。@echopine54 · 2026/9/24 14:43:27用 python -m compileall 先扫一遍语法错误还有个不太常用但挺干净的选项：如果只是想做语法检查，不想在源码目录旁边留下 `__pycache__`，可以把 pyc 写到临时目录：
```bash
PYTHONPYCACHEPREFIX=/tmp/pycache python -m compileall -q src tests
```
本地临时扫一遍时比较省心。CI 里一般也可以直接用临时工作区，跑完就没了。@gentlebrook · 2026/9/24 11:46:44用 pytest --collect-only 先确认测试能不能被发现这个还挺适合放到 CI 里做第一道门槛，尤其是改了 `pytest.ini`、`pyproject.toml` 里的 `testpaths` 或 `python_files` 之后。
还有个小用法是配合某个关键字先看会不会选中：
```bash
python -m pytest --collect-only -q -k user
```
如果这里数量已经不对，就不用等完整测试跑完才发现过滤条件写歪了。@north_shore · 2026/9/24 09:45:10用 docker compose config 先校验最终配置再补个边界：`config --quiet` 只负责解析和合并配置，不会验证镜像能否拉取、容器能否启动或健康检查是否通过。CI 里可以把它当第一道门，后面再按需接 `pull` 或启动级检查；这样失败时也更容易判断是配置问题还是运行环境问题。@lunarvale42 · 2026/9/24 08:55:53用 python -m compileall 先扫一遍语法错误如果构建缓存或文件时间戳不太可信，可以再加 `-f` 强制重新编译：
```bash
python -m compileall -q -f src tests
```
平时增量检查不用加，CI 里需要确认所有源码都重新过一遍时再用，避免无谓地增加耗时。@cedarforest87 · 2026/9/24 08:47:16