npm ci vs npm install: Preserve the Source Pack Before Changing It
An npm ci failure can expose a disagreement between a source pack’s manifest and lockfile. Deleting the lockfile removes the original comparison point before you have explained that disagreement. For a first installation, choose the command according to whether you intend to reproduce the supplied dependency selection or deliberately change it.
Use npm ci when a package lock exists, agrees with package.json, and the required dependency-resolution flags are known.
Use npm install when you intentionally need dependency resolution and can review any resulting lockfile changes.
Investigate first when the supplied files disagree or the installation conditions are unclear.
The free starting action is to read the files in a Node source project you already own. No purchase is needed to use this decision aid.
The receipt is documentation, not a successful installation
Evidence reviewed: 2026-09-09T09:20:58+09:00. Article date: 2026-09-11.
Test status and conditions: This is a documentation-based buying decision and installation playbook. No source-pack installation, production experiment, or customer outcome was tested for this article. Applying it requires checking your actual runtime, project configuration, and current official documentation.
The reviewed npm ci documentation establishes the relevant behavior: a package lock must exist; disagreement with package.json causes failure; an existing node_modules directory is removed; and the command does not rewrite the manifest or lockfile. Dependency-resolution flags should match those used to create the lockfile.
The reviewed npm install documentation supplies the distinction: it uses a lockfile when that file satisfies the manifest ranges, but can resolve dependencies and update the lockfile when they disagree.
These are command-behavior receipts. They do not establish that a particular source package installs or runs successfully.
The useful distinction is whether you want to preserve the supplied dependency selection or intentionally revise it.
Read the package before choosing the command
Start with package.json, the package lock, the installation guide, and any supplied project configuration.
In package.json, inspect the dependency declarations and look for runtime or package-manager requirements. Then establish whether the package includes a lockfile. Its presence matters, but presence alone does not establish agreement with the manifest.
Next, look for the prescribed installation command and dependency-resolution flags. Compare the guide with the supplied configuration. If the command requires flags, their purpose belongs in your installation notes.
Do not assume that a guide saying “install dependencies” settles these questions. For a buyer evaluating a source license, a documented installation path is useful evidence about what must be checked. It is still separate from verified execution.
Preserve an untouched copy before attempting installation. Because npm ci removes an existing node_modules directory, use a working copy where that removal is acceptable.
A choice table for the first run
| What you find | Decision | What to preserve or verify |
|---|---|---|
| A package lock exists, agrees with the manifest, and required flags are documented | Choose npm ci to reproduce the supplied selection | Original files, runtime requirements, configuration, and command |
| No package lock is supplied | npm ci is unavailable under its documented requirements | Check whether the guide intentionally calls for npm install |
| The manifest and lockfile disagree | Pause a reproduction attempt | Keep both original files and the complete error |
| You intentionally changed dependency declarations | Consider npm install to resolve that change | Review the resulting lockfile differences |
| The lockfile’s dependency-resolution flags are unclear | Clarify configuration before retrying | Compare the guide, project settings, and required flags |
| Installation fails without an identified manifest disagreement | Diagnose the reported error | Do not assume switching commands addresses it |
Artifact caption: First-install decision table comparing manifest agreement, package-lock availability, and dependency-resolution flags. This is a reusable decision aid, not a captured installation result.
The table makes the intent explicit. npm install does not necessarily discard a valid lockfile: the documented behavior is to use it when it satisfies the manifest ranges. Likewise, choosing npm ci does not establish compatibility with your environment.
A failed command needs a named cause
There are distinct branches worth keeping separate.
Missing package lock. The documented prerequisite for npm ci is absent. Check the delivery and installation guide before deciding whether to generate a lockfile through npm install.
Manifest disagreement. npm ci refuses the supplied combination. Preserve it. For an unchanged source package, ask whether the files belong to the same release and request a consistent set or an explained correction.
Dependency-resolution flags. The documentation says these should match the flags used when creating the lockfile. Compare the documented command with the project configuration before adding or removing flags.
Another reported error. The evidence here does not provide an exhaustive installation troubleshooting guide. Keep the full error and investigate its actual subject. A command change without a diagnosis leaves the original question unresolved.
These are documented conditions and recommended diagnostic branches, not failures observed in a Builderlog installation.
A successful retry would not, by itself, explain why the original installation failed.
What a deliberate repair should leave behind
Hypothetical example: A fictional convenience-store deals source pack includes a manifest and lockfile that disagree. Its buyer runs npm install, which resolves dependencies and changes the lockfile.
That behavior is consistent with the documentation. It does not prove the delivered files were reproducible as supplied.
A reviewable repair keeps the original files, records the disagreement, explains why dependency resolution was intentional, and retains the resulting changes for inspection. Any subsequent build or application check needs its own recorded result.
Deleting the lockfile at the outset makes that comparison harder. If you intentionally replace it, preserve the original first and describe the replacement as a dependency change. Avoid reporting it as a faithful reproduction of the delivered selection.
Copy this installation decision record
Use this before running either command:
- Purpose: Reproduce supplied dependencies, or intentionally revise them?
- Manifest: Which dependency declarations and runtime requirements apply?
- Package lock: Present, absent, or agreement still unverified?
- Configuration: Which dependency-resolution flags does the guide require?
- Working copy: Are original files preserved and directory removal acceptable?
- Chosen command: What evidence supports this choice?
- Failure evidence: What did the complete error actually report?
- Changes: Did the manifest or lockfile change, and why?
- Outcome: Installation result recorded separately from application execution?
Unknown is a useful entry. It identifies the next check without inventing compatibility or success.
The buying decision comes after the free check
The optional Saju source-license example is a Korean web-app source license for one project. Its product page is the reference for current price, deliverables, and installation requirements.
Apply the same table when reviewing its stated conditions. The product description does not establish a customer installation outcome or compatibility with every runtime. Where supplied-file evidence is unavailable before purchase, leave that part of the evaluation unresolved.
Final decision: Choose npm ci for a documented reproduction path. Choose npm install for intentional resolution that you can review. Preserve unexplained failures before attempting a repair.
Your next action: open a source project you already own and fill in the decision record before installing anything.
Related build logs
Choose npm ci to preserve an agreed dependency selection; choose npm install for intentional resolution, and keep the original evidence when installation fails.