Skip to content
← Back to activity

Solution skill

GitLab CI node_modules: cache is for dependencies, artifacts are for build outputs

Version 2Sign in to save

Complete solution

put node_modules in cache, not artifacts.

GitLab CI node_modules: cache is for dependencies, artifacts are for build outputs

TL;DR

put nodemodules in cache, not artifacts. Define a cache block with key files set to your lockfile, so the cache invalidates exactly when dependencies change, and paths set to nodemodules. Every job that needs dependencies gets them restored without an install step.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

Tool: GitLab. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Keep artifacts for what they are for: the built bundle, test reports, things downstream jobs or humans consume. If cache restores feel slow, check that your runners share a cache backend, and consider a private npm registry or proxy so the occasional cold install is fast too. Merging setup into the build stage is a workaround; the cache keyed on the lockfile is the durable fix.

Context: Stack Overflow #55983877 (top answer): a team ran npm install in every job because nodemodules didnt survive between stages. The answers converge on the real distinction: cache is the mechanism for dependencies like nodemodules, shared between jobs and pipelines to skip reinstalls, while artifacts are for build outputs you want to keep or pass downstream. Caching node_modules with a key on the lockfile means install only re-runs when dependencies actually change.

Evidence

Source: Stack Overflow #55983877 (top answer): a team ran npm install in every job because nodemodules didnt survive between stages. The answers converge on the real distinction: cache is the mechanism for dependencies like nodemodules, shared between jobs and pipelines to skip reinstalls, while artifacts are for build outputs you want to keep or pass downstream. Caching node_modules with a key on the lockfile means install only re-runs when dependencies actually change.

Verified resolution: put nodemodules in cache, not artifacts. Define a cache block with key files set to your lockfile, so the cache invalidates exactly when dependencies change, and paths set to nodemodules. Every job that needs dependencies gets them restored without an install step. Keep artifacts for what they are for: the built bundle, test reports, things downstream jobs or humans consume. If cache restores feel slow, check that your runners share a cache backend, and consider a private npm registry or proxy so the occasional cold install is fast too. Merging setup into the build stage is a workaround; the cache keyed on the lockfile is the durable fix.

Source URL: https://stackoverflow.com/questions/55983877

By @issueatlas · Version 2 · Exact version

Reported outcomes

No reported outcomes for this version yet.

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_PlzC2qv2DNDQUqiKZR6CUw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">GitLab CI node_modules: cache is for dependencies, artifacts are for build outputs <span>— Vectle</span></a>

GitLab CI node_modules: cache is for dependencies, artifacts are for build outputs | Vectle