[Feature] Metadata-Only Output

[jlucaso1]

An option (maybe --metadata-only) to output just the summary, directory structure, and file metrics without the content, useful for quick analysis.

[massdo]

That would be very useful, and also a parsable json format to integrate with other tool (like repomix runner extension)

maybe a --report and --report-json flags ?

[yamadashy]

@jlucaso1 cc: @massdo
Thanks for the suggestion!

We actually already have boolean options like output.fileSummary and output.directoryStructure, so for consistency, adding an output.files option seems like a good fit.

If files is set to false, only the metadata and directory structure will be included in the output.

We can also add a corresponding CLI flag --no-files, similar to the existing --no-file-summary and --no-directory-structure flags.

[yamadashy]

The implementation has been merge into main. Please wait for the release.

• Add metadata-only output mode with --no-files flag #491

[yamadashy]

@jlucaso1 cc: @massdo
This has been released as part of v0.3.3!
You can now use the --no-files flag to output only metadata and directory structure.

Check it out here:
https://github.com/yamadashy/repomix/releases/tag/v0.3.3

Thanks again for the great suggestion!

[iliakan]

Nice! What is the repomix config file option for this?

[yamadashy]

@iliakan
In your repomix.config.json you can reproduce the --no-files flag by turning off the output.files field!

{
  "output": {
    "fileSummary": true,
    "directoryStructure": true,
    "files": false
  }
}

[iliakan]

Thanks! It worked! Great tool!

If I might ask...

Sometimes it's important to provide the full file structure, but only content some of the files to LLM.

E.g. to debug a build system - let it see the full configuration & build system-related files and the overall file structure of the project.

Is there a way to do so with the current config?

If not, perhaps a feature request may be meaningful to allow providing 3 separate sets of files for: full content / compressed / directory-only files.

This would allow us to flexibly decide on what to pack and how much detail to provide to satisfy task needs and keep LLM context length in check.

[yamadashy]

Thanks for the question!

Regarding compression, does --compress meet your requirements?
https://github.com/yamadashy/repomix?tab=readme-ov-file#code-compression

With today’s features you can already do:

1. Full content (default)
2. Compressed content (--compress / output.compress: true)
3. Directory structure only (--no-files / output.files: false)

If this doesn’t quite cover your use case, please feel free to let me know!

[iliakan]

I think that's not it, unless I'm missing some of their functionality 😀

What I mean is the smart way to form the LLM-input by providing:

1. Full content for a set of the most important files.
2. Compress less important ones, which still may be relevant.
3. Add to directory structure the bigger set which doesn't contribute to context, but LLM still needs to be aware that such files exist.

One can think of it as nested sets which describe not just the files, but the level of their detalization:

[ File in directory structure] < [ Compressed file ] < [ Full file ]

Use case: we need to improve build system.

1. Full files: for all configs and build files.
2. Directory structure: full folder structure.

Use case: we need to work on a module residing inside a certain folder:

1. Full files: the whole module, main project files, configuration
2. Compressed files: other modules which somewhat contribute to context, but details aren't important.

We can invoke a packing scenario via MCP.

[yamadashy]

@iliakan
I think I’m starting to get it—or rather, is it the idea of introducing a “mode” concept under the output settings so you can switch between full, compress, or structure-only?

{
  "output": {
    // "full" | "compress" | "structure"
    "mode": "compress"
  }
}

And on the CLI:

repomix --mode compress

That feels much more intuitive from a UX standpoint.

This feature doesn’t exist yet, so if you’d like to see it, I’d really appreciate it if you could open an issue for it. Thanks!

[iliakan]

Okey-dokey! #608