Build tools, test libraries and runtime packages have different roles. A smaller production installation is useful only when it still contains everything the running application needs.
IN THIS ARTICLE
What you need before you begin
Inspect the project’s dependency groups and build process. Identify packages needed for compilation, database tasks, dynamic imports and production startup.
01 Separate development and production dependency groups
Classify dependencies by actual use rather than package name. A library imported by production code belongs in the runtime set even if it was first added during development.
Install the required build and test tools in the controlled build stage. Run compilation and meaningful checks before removing build-only packages.
Prepare the runtime artifact through the package manager’s supported group or omission mechanism. Preserve generated outputs needed after compilation.
Test the artifact in a clean environment containing only the intended production dependency set.
Review the classification when adding a feature or changing a framework. A startup script that invokes a build tool changes the runtime requirements.
02 Example: classify a TypeScript backend build
| Component | Typical role in this example | Verification |
|---|---|---|
| TypeScript compiler | Build tool when production runs precompiled JavaScript. | The clean build produces the complete intended output. |
| Web framework imported by the generated JavaScript | Runtime dependency. | The production artifact starts without developer-global packages. |
Generated dist files |
Required release output. | Dynamic routes, templates and other runtime files are included. |
| Migration command dependencies | Required wherever the approved migration stage executes. | The release process can run that stage before activation. |
If production startup compiles TypeScript, the compiler is needed for that release design. Do not remove a tool solely because its package is listed under development dependencies; first complete or redesign the stage that uses it.
Confirm the expected result
Start the application and run a workflow that loads less common modules, templates and migration tools. Confirm the release does not silently depend on globally installed developer packages.
Troubleshoot unexpected results
A missing compiler during build means development tools were omitted too early. A missing library at runtime means classification or packaging is incomplete.
A common question
Can I remove all development dependencies immediately after installation?
Only after completing the steps that need them and verifying the resulting runtime. Follow the project’s chosen release model rather than a blanket deletion rule.