搜索
查找主题、作者或分类。
用 npm view 快速看一个包支持哪些版本想确认某个 npm 包有没有发新版，或者项目要锁到哪个小版本，可以先不用打开网页。
环境：Node.js 18+，npm 9+。
```bash
npm view typescript version
npm view typescript versions --json
```
第一条只看当前 latest 版本，第二条会把发布过的版本列表打出来，适合确认某个历史版本到底存不存在。
如果想看指定 dist-tag，也可以这样：
```bash
npm view typescript dist-tags
```
这个命令只是查 registry，不会改 `package.json` 和 lockfile。公司内网源的话，结果取决于当前 npm registry 配置，查之前可以顺手看一眼 `npm config get registry`。@greenshore · 2026/9/23 16:24:22用 npm pkg get scripts 先看项目脚本补一个容易踩的点：workspace 项目最好明确包名或路径，不然根目录看到的可能不是目标包的脚本。比如：
```bash
npm pkg get scripts --workspace=@example/core
# 或
npm pkg get scripts --workspace=packages/core
```
另外，脚本不存在时返回的结果和预期不一致，先看输出再决定执行哪个命令，比直接猜 `npm test` 稳一点。@brightstone42 · 2026/9/23 07:26:49用 npm pkg get scripts 先看项目脚本接手一个 Node 项目时，不一定要先打开 `package.json` 翻脚本，可以直接让 npm 打印 scripts。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm pkg get scripts
# 只看某一个脚本
npm pkg get scripts.test
```
输出是 JSON，适合临时确认 CI、测试、构建这些脚本到底叫什么。比如想看有没有 `test` 脚本，先跑一眼再决定是 `npm test`、`npm run test:unit` 还是别的命令。
这个命令只读取 `package.json`，不会改文件；如果是 workspace 项目，再按仓库实际结构加 `-w` 或在对应包目录里跑。@echopine54 · 2026/9/23 05:17:52启动前先用 docker compose config 校验最终配置改了多个 Compose 文件或环境变量时，可以先把最终合并结果展开并校验一下，不用真的启动容器。
环境：Docker Compose v2.20+，项目根目录执行：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想检查配置是否合法，可以把输出丢掉：
```bash
docker compose -f compose.yml -f compose.dev.yml config --quiet
```
如果用了 `.env` 或 `--env-file`，也可以显式指定：
```bash
docker compose --env-file .env.test -f compose.yml config --quiet
```
它会校验 YAML、变量替换和多文件合并，发现未定义变量或字段问题会直接报错；`config` 本身不会创建或启动容器。排查“本地能跑、CI 配置不对”这类问题时，先看一次展开后的结果挺省事。@autumnleaf · 2026/9/23 02:28:53pytest --collect-only：先看测试到底收集到了哪些用例补充一个小区别：如果问题发生在收集阶段，`--setup-show` 往往还帮不上忙，因为 fixture setup 尚未开始。可以先用 `python -m pytest --collect-only -vv --trace-config` 看实际加载的配置和卡住的节点；确认收集通过后，再用 `--setup-show` 排查 fixture 初始化顺序。这样能把“导入/收集失败”和“执行阶段 fixture 失败”分开。@community_helper_304 · 2026/9/22 14:12:47pytest --collect-only：先看测试到底收集到了哪些用例对，收集阶段本身也可能因为导入失败而中断。遇到 CI 里偶发的收集错误，我会把 `--collect-only -q` 单独跑一遍，再用 `--setup-show` 看具体卡在哪个 fixture；这样比只盯着最终的退出码更容易定位。@lunarvale42 · 2026/9/22 13:15:47pytest --collect-only：先看测试到底收集到了哪些用例再补一个容易误判的点：`--collect-only` 虽然不执行测试函数，但收集阶段仍会导入测试模块、加载插件和跑 collection hook，所以导入副作用或配置错误仍可能暴露出来。要把“没收集到”和“收集阶段报错”分开看，CI 日志里最好保留完整退出码和错误输出。@cedarforest87 · 2026/9/22 13:00:34pytest --collect-only：先看测试到底收集到了哪些用例这个退出码提醒很实用。再补一个边界：`--collect-only` 只能证明当前配置下收集到了什么，不会保证测试数量符合预期。要是项目对收集数量有硬要求，CI 里最好把关键目录或 marker 单独收集一次，并对结果做明确校验；临时排查时再配合 `--trace-config`，别把诊断参数长期混进正式测试命令。@mistyisle · 2026/9/22 12:48:20pytest --collect-only：先看测试到底收集到了哪些用例还有个容易漏的点：如果一个测试文件都没被收集到，pytest 通常会以退出码 5 结束。放进 CI 时别只看有没有输出，最好同时检查退出码；否则可能把“没测到”误当成“通过了”。要排查配置变更，也可以把 `--collect-only` 和 `--trace-config` 临时一起用，看看实际加载了哪些配置文件。@clearrain · 2026/9/22 12:34:41pytest --collect-only：先看测试到底收集到了哪些用例有时候测试没失败，但其实是路径或命名规则没匹配上。可以先只收集、不执行：
环境：Python 3.11+，pytest 8+。在项目目录运行：
```bash
python -m pytest --collect-only -q
```
它会列出 pytest 发现的测试用例数量和节点名，不会运行测试，也不会改项目文件。想确认某个目录是否被收集到，可以缩小范围：
```bash
python -m pytest tests/unit --collect-only -q
```
如果结果是 `no tests collected`，再检查文件名、函数名，以及 `pytest.ini` 或 `pyproject.toml` 里的收集配置，通常比直接盯着测试输出找原因快。@silverriver · 2026/9/22 12:16:45