Add include/exclude options specific to --compress

[stoopkidddd]

Going to take a stab at making a PR for this myself, but in the meantime wanted to put an issue up to track.

It'd be really useful to allow for --compress to have its own exclusive parameters to define what files should be compressed. Right now, it is all or nothing. But oftentimes, I have a certain section of the code base that is most relevant and I want to send the whole section in the context, and then compress the rest as a bonus.

Not entirely sure what the best CLI argument names would be, and which takes precedence. Right now there is --include and --ignore, so probably --compress-include and --compress-ignore.

But what happens if say, you put a file in --ignore and then also put it in --compress-include? Lots of open ended questions like that. Probably will be dictated by the structure of the code and what is easiest to implement once I dig in.

If anyone has thoughts please chime in.

[yamadashy]

Hi, @stoopkidddd !
Thank you for the great suggestion!
I actually had similar thoughts when initially implementing --compress.

It's still just a rough idea, but I’ve been considering a configuration format like this.
With this approach, we could support not only compress but other file processing options as well, and it could handle a wide variety of use cases.

{
  "output": {
    // ... output config
    "compress": false // default: no compression
  },
  "process": {
    "patterns": [
      {
        "pattern": "docs/**/*",
        "compress": true
      },
      {
        "pattern": "website/**/*",
        "compress": true,
        "removeEmptyLines": true
      }
    ]
  }
}

[yamadashy]

Introducing just --compress-ignore might actually be a simple and intuitive approach.

Having both --compress-include and --compress-ignore could lead to the kind of ambiguity you mentioned,
so my current instinct is to start with just --compress-ignore.
The idea is to enable compression globally to reduce overall token count, while selectively disabling it for important context.

For example, in the case of Repomix, if I want to focus on the src directory, the usage might look like this:

repomix --include "src,website,tests" --compress --compress-ignore "src"

I'll keep thinking on this a bit more!

[stoopkidddd]

Thanks for the reply @yamadashy! I do love that first suggestion as a long term goal for its extensibility.

I also agree about limiting it to --compress-ignore. That definitely seems the most sensible and sane approach to start with. I like that it avoids all of the precedence pitfalls.

[yamadashy]

@stoopkidddd
Thank you!
If you're up for it, it would be great if you could open a PR adding --compress-ignore (as output.compressIgnore in the config). That would be super helpful!

I'll go ahead and assign you to the issue if you're okay with it.

[yamadashy]

I’ll go ahead and assign this issue to you for now.
Please let me know if you have any questions or need anything—thank you!