Proposal: Introducing Template-Based Pattern Management

[Jeremy-F]

Context

First, let me start by saying how much I admire this repository. I truly believe it's an excellent idea with great potential. The simplicity of npmprune and its "integrate and forget" philosophy is exactly what makes it such a valuable tool.

In my previous pull request, I proposed adding support for additional patterns via CLI arguments. For example, I illustrated how one could exclude unnecessary image files (e.g., .png, .jpeg, .gif) from node_modules:

npmprune "*.png" "*.gif" "*.jpeg"

While this approach provided much-needed flexibility, I quickly realized its limitations in real-world use cases. For instance, in my scenario, I deploy AWS Lambda functions with code written in CommonJS. This means I have no need for the esm modules included in certain libraries. However, crafting long RUN commands in my Dockerfile to handle these exclusions quickly became cumbersome:

RUN wget -qO- https://raw.githubusercontent.com/xthezealot/npmprune/master/npmprune.sh | \
    sh -s -- "dist-es" "dist-esm" "dist/esm" "esm" "*.mjs" "*.umd.js" "*.png" "*.svg" "*.gif" "*.ico"

The more use cases I encountered, the more apparent it became that relying solely on manual CLI arguments is unsustainable. The core strength of npmprune—its simplicity—was being undermined by these verbose configurations.

Problem Statement

One of the key goals of this script, as stated in issue #1

is to maintain simplicity and generality - to make a simple "integrate and forget" solution (like Prettier does for code formatting)

I completely agree with this philosophy—it’s the reason I was drawn to this repository in the first place.

However, I believe that simplicity and extensibility are not mutually exclusive. In fact, enabling a standard, customizable way to clean node_modules can enhance the script's utility while preserving its core "integrate and forget" ethos. By making npmprune more extensible, we also provide room for "extremely aggressive" use cases without compromising safety for standard use.

Proposal

To address this, I propose the introduction of template-based pattern management through a new -t (template) flag. This flag allows users to apply predefined templates of patterns for specific use cases. For example:

• To remove image files:

  ./npmprune.sh -t images

• To remove esm-related files:

  ./npmprune.sh -t esm

• To combine templates:

  ./npmprune.sh -t images,esm

This approach allows users to apply common cleaning patterns effortlessly, without relying on long CLI arguments or custom scripts. It also opens the door for the community to contribute and share templates for specific scenarios, fostering the development of a flexible and community-driven standard for cleaning node_modules.

Implementation Highlights

1. Template Management:

   • Templates are stored in a templates/ directory and can be easily extended.
   • Examples:
     • images: Patterns for image files (*.png, *.jpeg, *.gif, etc.).
     • esm: Patterns for esm-specific files (*.mjs, dist-es, etc.).
     • default: The original hardcoded patterns for general cleanup.
     • aws: Patterns specific to AWS SDK files (aws-sdk/dist, aws-sdk/dist-tools).
     • To be completed

2. Overridable Templates:

   • Templates are fetched from a base URL that can be overridden via an environment variable:
   • This feature was added specifically to facilitate local testing and development. For example, you can point the script to a local directory of templates:

     TEMPLATE_BASE_URL=`pwd`/templates ./npmprune.sh -t default,images

   • This makes it easy to develop and test new templates without relying on remote repositories or pushing changes unnecessarily.

3. CLI Integration:

   • The -t flag enables one or more templates to be applied dynamically.
   • Templates can be combined for maximum flexibility:

     ./npmprune.sh -t images,esm

4. Backward Compatibility:

   • The -t flag does not interfere with the original functionality. Users can still provide patterns directly as CLI arguments.

     ./npmprune.sh ".husky" -t images,esm

5. Safety Features:

   • The script exits gracefully if no valid patterns are found.
   • A log function suppresses unnecessary output in production environments (NODE_ENV=production).

Potential Drawback

The main drawback introduced by this change is that the script now relies on either wget or curl to fetch templates dynamically. This adds a slight dependency overhead. However, given that wget is commonly available in Docker environments (where this script is likely to be used), this should not pose a significant issue. In fact, the original idea of this script was to integrate it directly into Docker image creation using wget, so this change aligns well with its intended use case. For environments where wget or curl are unavailable, users can still provide their own local templates as files.

Future Documentation

If this proposal is accepted, I will write the necessary documentation to explain how to use the -t flag with existing templates (default, images, esm, aws).

Closing Thoughts

This proposal does not aim to force any new behavior but rather to enhance the flexibility of npmprune while staying true to its original philosophy. By introducing templates, we make the script more powerful and community-driven, allowing it to handle both simple and complex use cases with ease.

Thank you for considering this proposal! I’m happy to make any adjustments based on your feedback.

[Jeremy-F]

Hello,

With some time and reflection, I believe the pull request is too impactful and changes the initial simplicity of the project.

If you're okay with it, @xthezealot, I'll continue developing this idea further on my fork.

I'll go ahead and close the pull request.

Thank you!

[xthezealot]

Hi @Jeremy-F,

Your feature looks great.
I just haven't had time yet to read the code to do the merge (as I haven't worked with Node.js for a few months).

I'll pick this up in a few months.
Thanks again!