Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

CD workflows use `npm install` instead of `npm ci`, so deploys can drift from the lockfile

オープン 初心者向け
  • 何か問題がありますか？
#130 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
90/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
github-actions, javascript
領域
ci-cd, devops

調査の方向性

.github/workflows/cd_dev.yaml と .github/workflows/cd_prod.yaml に記載された4つのインストール手順から始め、次にそれらを tests.yaml にある既存の npm ci 手順と比較します。各 CD の npm install コマンドを npm ci に置き換え、テストコマンドとデプロイフローは維持します。4つすべての CD 手順がロックファイルを強制するコマンドを使用し、オプションの --omit=dev の動作を変更していなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

dependencies enhancement

Summary

tests.yaml installs with npm ci, but all four install steps in the CD workflows use npm install. npm ci installs exactly what package-lock.json pins; npm install is free to resolve newer in-range versions and rewrite the lockfile. The result is that the dependency tree CI validates is not necessarily the tree that runs on vlcdhp02 or vlcdhprdp02.

Affected steps

File Line Job Runs on Needs devDeps?
.github/workflows/cd_dev.yaml 55 test ubuntu-latest yes (npm run allTests)
.github/workflows/cd_dev.yaml 84 deploy vlcdhp02 no
.github/workflows/cd_prod.yaml 20 test vlcdhprdp02 yes (npm run allTests)
.github/workflows/cd_prod.yaml 46 deploy vlcdhprdp02 no

For contrast, tests.yaml:27 and tests.yaml:47 already do this correctly.

Why it matters

1. Deploys are not reproducible. A caret range like ^17.4.2 lets the server resolve a different version at deploy time than CI tested. This directly undercuts lockfile work — #128 pins a tree, verifies it passes npm audit, npm-check, and the full suite, and then the deploy step is free to install something else.

2. Silent drift stays silent. npm ci fails loudly when package.json and package-lock.json disagree. npm install quietly reconciles them. A stale lockfile can therefore ride along unnoticed — which is exactly what happened to the lockfile root version field, stuck at 0.1.1 on main while package.json said 1.0.0 until #128 regenerated it.

3. cd_prod.yaml runs both jobs against the same directory on the same box. The test job does npm install in /srv/node/tiny-node/, then the deploy job does git stash && git checkout main && git pull && npm install in that same directory. If the first npm install rewrites package-lock.json, the working tree is now dirty and the git stash masks it rather than surfacing it. With npm ci the lockfile is never written, so there is nothing to stash.

4. The dev cache is already configured for npm ci. cd_dev.yaml:41-52 caches ~/.npm keyed on hashFiles('**/package-lock.json'). That is the npm download cache, which is precisely what npm ci consumes — so this swap costs nothing on the hosted runner and arguably speeds it up.

Proposed change

Replace npm install with npm ci in all four places. Minimal and behavior-preserving:

# .github/workflows/cd_dev.yaml:53-56
      - name: Install dependencies and run the test
        run: |
          npm ci
          npm run allTests

# .github/workflows/cd_prod.yaml:14-21
      - name: Test the app on the server
        run: |
          cd /srv/node/tiny-node/
          git stash
          git checkout main
          git pull
          npm ci
          npm run allTests

The two deploy steps (cd_dev.yaml:84, cd_prod.yaml:46) take the same npm ci swap.

Optional refinement, with a tradeoff

The deploy steps only need runtime dependencies, so npm ci --omit=dev would work there and would keep playwright, c8, and supertest off the production server. The cost: after a deploy, running npm run allTests by hand on that box fails until someone reinstalls devDeps. Since cd_prod.yaml runs its test job in the same directory, the next pipeline run would reinstall them anyway — but manual on-server testing between deploys would break. Worth deciding deliberately rather than folding into this change by default.

Caveats

  • npm ci deletes node_modules before installing, so it is slower than a warm npm install on the self-hosted boxes. The reproducibility is the point, but the added minute per deploy is real.
  • npm ci hard-requires package-lock.json to be present and in sync. That is the desired behavior, but it means a future PR that edits package.json without regenerating the lock will now fail CD instead of silently self-correcting.

Context

Found during static review of #128. Related to #124, which covers the other reproducibility gap in these same CD workflows (actions pinned to @master rather than a release tag).

主要言語
JavaScript
スター
1
フォーク
3
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CenterForDigitalHumanities/TinyNode のほかの issue

CenterForDigitalHumanities/TinyNode の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。