Files "inclusion level"

[iliakan]

Create a way to provide the detalization level for packed files.

There are 3 levels:

1. Full content - for a set of the most important files.
2. Compress - for the less important ones, which still may be relevant.
3. Directory-only - mention in the directory structure.

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 file 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.

Then we'll be able to create packing scenarios with various such settings and invoke them via MCP.

The simplest syntax would be 3 settings, e.g.

files: {
  content: [...globs...],  // full content
  compress: [...globs...], // compressed
},
directory: [...globs...] // only list in the file structure

1. If a file matches a glob in content - full content is included.
2. Otherwise, if it matches a glob in compress - it gets compressed

So we can have like compress: **/*.ts, content: my.ts - all ts will be compressed, but my.ts will be included fully.

Also, all mentioned files are included into the directory structure, together with directory globs.
The directory globs has precedence over all ignores.

Here, the directory setting is the least important one, but it still may matter for huge projects with many files and folders. I understand we already have some ignore settings, perhaps they can replace directory or somehow make it into the mix =)

[yamadashy]

Hi, @iliakan !
Thank you for creating this issue and the excellent proposal!

I've been thinking about how to implement this feature while maintaining harmony with the existing configuration structure as much as possible.

This is still a draft, but I believe the following configuration approach could provide the flexibility you're looking for while maintaining compatibility with existing implementations and settings:

{
  "output": {
    "compress": false, // Global setting - currently the only configurable option
    // Pattern-specific settings that can override global configuration
    "patterns": [
      {
        "pattern": "docs/**/*",
        "compress": true
      },
      {
        "pattern": "website/**/*",
        "directoryStructureOnly": true
      }
    ]
  }
}

This approach would:

1. Maintain backward compatibility
2. Enable the three levels you proposed
   • compress: false` → Full content
   • compress: true` → Compressed content
   • directoryStructureOnly: true` → Directory structure only
3. Support pattern/priority control: patterns are processed in array order, allowing fine-grained overrides

Additionally, this pattern-based approach would also allow flexible control over other settings like "removeComments": false and similar options on a per-pattern basis.

What do you think about this approach?

[iliakan]

Hello Mr.Yamada,

Backwards compatibility is definitely a good thing!

I like the idea of patterns array - makes it easy to just say: "the first matching pattern defines the level, 'no match' means 'ignore file', unless there's a default option".

The outer compress and perhaps some other options will only apply if there's no matching pattern, so they can serve as "catch-all".

P.S. We need to think about the speical case when a directory matches the pattern. A directory may be needed in the structure even if it's empty or if we don't need files in it.