prunify-modules

like npm prune --production just better

prunify-modules is a lightweight Node.js tool that helps you efficiently prune unnecessary dependencies from your node_modules folder, tailored to your production environment’s needs.

Considering a Dockerfile...

with the setup of multi-stage builds for a moderate sized (un-optimized) application - with about 50 prod dependencies:

```Dockerfile


Base stage

CMD ["node", "/build/server/index.js"]
``

Because of the node_modules folder that gets copied to the last stage the docker image size is:

| REPOSITORY | TAG | IMAGE ID | CREATED | SIZE |
|---------------------|--------|----------|----------------|--------|
| app-unoptimized | latest | xxx | xx seconds ago | 1.25GB |

Doing a deeper analysis with dive - a Docker image analysis tool - it is visible which part of the app is responsible for its size:

On the contrary...

Applying a small change to the Dockerfile:

``Dockerfile
RUN if [ "${NODE_ENV}" = "production" ]; \
prunify-modules --externals @datadog,react,react-dom,react-intl,@sentry/browser,@sentry/core --prune typescript,babel,react-native,@types,eslint \
fi
``

can make a significant impact on the image size:


| REPOSITORY | TAG | IMAGE ID | CREATED | SIZE |
|-------------------|--------|----------|----------------|---------|
| app-optimized | latest | xxx | xx seconds ago | 230MB |

which is even in the analysis of the image visible:


Since now we clarified the impact of change...

So why using prunify-modules?

* Considering docker best practices it is typically recommended to use slimmer docker images that are dedicated for running the application, in order to also reduce the attack surface of an container: Docker recommendations
* When using a service for storing your Docker images you might be billed by GB storage usage: Like AWS ECR. It is possible to significantly reduce the storage costs
* The utilized startup resources (on request resources) for an application-container on Kubernetes is significantly lower compared to an un-optimized container. Furthermore, also the avg resource utilization can be around 16% less (in our example)


Usage

The prunify-modules CLI offers some options to customize how dependencies are pruned from your node_modules directory. Here’s an overview of the available options:

Keep in mind that when using bundlers to package imported third-party code, it may sometimes be necessary to externalize certain dependencies, such as native C++ modules, as they cannot be processed by the bundler. In such cases, externalizing these dependencies becomes essential.

$3

| Option | Alias | Description | Default Value |
|-----------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------|-------------------|
| --dry-run | -d | Lists dependencies that would be pruned without actually deleting them. Use this to preview the impact of pruning. | false |
| --externals | -e | A comma-separated list of dependencies to exclude from pruning. Transitive dependencies of these externals will also be retained. | [] |
| --prune | -p | A comma-separated list of dependencies to explicitly prune, even if they are marked as production dependencies. | [] |

$3

`bash
prunify-modules --externals react,react-dom,@sentry/browser
`

Expected output:

`
node_modules size un-optimized being: xxx MB
Pruning node_modules
Pruning complete
node_modules size optimized being: xxx MB 🚀
`

Explicitly remove certain dependencies even if they are marked as production dependencies:

`bash
prunify-modules --prune typescript,@types,babel
`

Explanation:
- Dependencies like: typescript, @types, and babel will be forcibly removed, even if they are present as production dependencies.

$3

Exclude specific dependencies while also forcing others to be pruned:

`bash
prunify-modules --externals react,react-dom --prune typescript,eslint
`

Explanation:
- The external dependencies react and react-dom (and their transitive dependencies) will not be pruned.
- The dependencies typescript and eslint will be explicitly removed.

$3

prunify-modules also provides programmatic access via its CLI class. This is useful when integrating the pruning functionality into custom scripts or automation workflows.

`ts
import { PrunifyCli } from "prunify-modules";

// Configuration options for pruning
const options = {
externals: ["@datadog", "react", "react-dom"], // Dependencies to keep
prune: ["typescript", "eslint"], // Dependencies to explicitly prune
dryRun: false, // Preview the pruning process without deleting files
};

// Initialize the Prunify CLI with the options
const prunify = new PrunifyCli(options);

// Run the pruning process
(async () => {
try {
await prunify.run();
} catch (error) {
console.error("Pruning failed:", error);
}
})();
``