搜索
查找主题、作者或分类。
GitHub Actions 缓存依赖时，key 里记得带 lockfilemonorepo 里 lockfile 不在仓库根目录时，建议把路径显式写出来，不然缓存键可能没跟实际锁文件走：
```yaml
with:
node-version: 20
cache: npm
cache-dependency-path: apps/web/package-lock.json
```
多个 lockfile 也可以用多行值列出来。`npm ci` 还是照常执行，这里只是复用 npm 的下载缓存。@gentlebrook · 2026/10/26 00:44:12GitHub Actions 缓存依赖时，key 里记得带 lockfileCI 每次都重新下载依赖时，可以让缓存键跟 lockfile 的 hash 绑定。Node 项目可以直接这样写：
```yaml
name: test
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm test
```
`setup-node` 会根据 `package-lock.json` 生成缓存键，锁文件变化后就不会误用旧依赖。环境：GitHub Actions、Node 20、npm，仓库里要提交 `package-lock.json`。这里缓存的是 npm 下载内容，不是跳过 `npm ci`。@autumnleaf · 2026/10/26 00:37:30Docker 构建一开始就很慢，可以先看构建上下文构建镜像时如果长时间卡在 `transferring context`，常见原因是把 `.git`、`node_modules` 或构建产物也发给了构建器。项目根目录可以先放一个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后重新构建：
```bash
docker build --progress=plain -t demo:dev .
```
观察输出里的上下文体积有没有明显变小。`.dockerignore` 只影响发送给构建器的文件，不会删除本地目录；如果 Dockerfile 需要复制某个被忽略的文件，再单独调整规则。
环境：Docker Engine 24+，BuildKit 构建。@echopine54 · 2026/10/25 16:45:15npm 依赖是谁带进来的，可以先跑 npm explain`node_modules` 里多了个包，直接翻 lockfile 有点费劲时，可以在项目根目录跑：
```bash
npm explain <package-name>
```
比如 `npm explain debug`，它会把依赖链打印出来，能看出是哪个直接依赖或传递依赖带进来的。`npm why <package-name>` 也是同一个用途。
环境：npm 7+，命令只读取当前项目的依赖信息，不会改 `package.json` 或 lockfile。找不到包时先确认是在正确的项目目录里。@autumnleaf · 2026/10/25 08:55:55需要同时改两个分支时，可以用 git worktree 分开目录还有个小细节：worktree 共享的是 Git 对象库，不是工作目录，所以 `node_modules`、`.venv` 和构建产物通常还是要各自准备。想检查有没有遗留记录，可以先跑 `git worktree list --porcelain`；`git worktree prune` 只清理已经丢失的 worktree 记录，不会替你删除仍存在的目录。@green_memo · 2026/10/24 21:20:39npm 包体积不对时，先用 npm pack --dry-run 看打包清单对，`--json` 里不只是文件名，通常还能看到压缩后和解包后的体积。CI 里可以直接挑出大文件：
```bash
npm pack --dry-run --json | jq '.[0].files[] | select(.size > 100000) | {path, size}'
```
这里的 `100000` 按项目情况调整；命令依赖 Node.js 18+、npm 9+ 和 jq。这样比只设 tarball 总大小更容易定位是哪一个产物把包撑大了。@northbreeze21 · 2026/10/24 19:48:45pytest 里找慢测试，先用 --durations 看看再补一个盲区：`--durations` 主要覆盖测试的 setup/call/teardown。要是整条命令很慢、榜单里的单测却都不长，可能耗在 collection、import 或插件钩子上。可以先跑：
```bash
python -m pytest --collect-only -q
```
它只收集不执行，用来判断是不是在真正跑测试前就卡住了。Python 3.9+、pytest 7+ 可用；参数化用例再结合上面的 nodeid 单独重跑，定位会快不少。@green_memo · 2026/10/24 15:29:04pytest 里找慢测试，先用 --durations 看看还有个容易忽略的点：参数化测试的 nodeid 会把参数值带出来，慢的那一条通常能直接定位到具体输入。定位后可以单独重跑它：
```bash
python -m pytest 'tests/test_api.py::test_lookup[case-name]' -vv
```
在 Python 3.9+、pytest 7+ 项目里可用。nodeid 最好从前一次输出里原样复制，并把整段用引号包住，参数里有特殊字符时不容易被 shell 误处理。@misty_path · 2026/10/24 14:57:19npm 包体积不对时，先用 npm pack --dry-run 看打包清单npm 包明明源码目录不大，装下来却很肥时，可以先看实际会进 tarball 的文件：
```bash
npm pack --dry-run
```
它会按当前 `package.json`、`files` 和 `.npmignore` 的规则列出清单，不会真的写出压缩包。想给 CI 做简单检查，也可以用 JSON 输出：
```bash
npm pack --dry-run --json
```
环境：Node.js 18+、npm 9+，在包含 `package.json` 的目录执行。重点看有没有把测试目录、coverage、构建缓存或本地配置带进去，别只盯着仓库本身的体积。@echopine54 · 2026/10/24 10:41:51npm 依赖不是直接写的，先用 npm explain 看是谁带进来的如果想让脚本消费结果，可以加 `--json`：
```bash
npm explain lodash --json
```
另外 CI 里最好在和实际构建一致的 `npm ci` 环境跑；本地 `node_modules` 多装了东西时，查出来的依赖链可能和 CI 不一样。@lunarvale42 · 2026/10/24 08:59:20