Feature request: improved per-file logging after recursive directory support

[DevTwilight]

Since recursive directory formatting was added in commit 88a6ea7, it would be great to improve the logging behavior when working on full projects.

Right now, CI usage typically relies on explicit per-file iteration, for example:

name: Check Code
run: |
  find "addons/messagebox" -name "*.gd" -print0 | while IFS= read -r -d '' file; do
    echo "Checking: $file"
    gdscript-formatter --check "$file" || echo "Found formatting issue in $file"
  done

- name: Lint Code
run: |
  find "addons/messagebox" -name "*.gd" -print0 | while IFS= read -r -d '' file; do
    echo "Linting: $file"
    gdscript-formatter lint --pretty "$file" || echo "Found Linting issue in $file"
  done

- name: Format Code
if: github.event_name == 'push'
run: |
  find "addons/messagebox" -name "*.gd" -print0 | while IFS= read -r -d '' file; do
    echo "Formatting: $file"
    gdscript-formatter --safe "$file" || echo "Code formatting failed in $file"
  done

- name: Reorder Code
if: github.event_name == 'push'
run: |
  find "addons/messagebox" -name "*.gd" -print0 | while IFS= read -r -d '' file; do
    echo "Reordering: $file"
    gdscript-formatter --reorder-code "$file" || echo "Reordering failed in $file"
  done

This works well, but now that recursive directory support exists, it feels like the tool is moving toward handling multi-file/project-wide workflows natively.

Proposed improvement

I propose a better default per-file logging format when processing multiple files (recursive mode or folder input) that matches the existing CI pattern.

Suggested output style

  Checking: addons/messagebox/core/parser.gd
  OK
  
  Checking: addons/messagebox/core/tokenizer.gd
  Found formatting issue in addons/messagebox/core/tokenizer.gd

Or depending on the command:

  Formatting: file.gd
  OK
  
  Linting: file.gd
  Found linting issue in file.gd
  Reordering: file.gd
  OK

Why this improvement helps

• Matches existing CI expectations (same “Checking/Linting/Formatting” style)
• Keeps logs grep-friendly and readable in GitHub Actions
• Reduces duplication when moving from find ... | while read to native folder mode
• Makes recursive execution feel like a natural extension of current behavior, not a different system

[NathanLovato]

Thank you for the proposal. I personally don't use something like a formatter in CI so it's helpful to get feedback from someone who does.

So right now, from what I see is you have your own logging in CI and you're suggesting making that the default output for the program. Is that correct?

For me, it's most important that first and foremost, the output format is clear and detailed for the most common use, which is the command line usage. But we can certainly find a good balance between having something clear and that preserves the current behavior in the Godot add-on and in the command line, while having something consistent and convenient for the CI.

[DevTwilight]

So right now, from what I see is you have your own logging in CI and you're suggesting making that the default output for the program. Is that correct?

yes kind of

[NathanLovato]

Could you please tell me more about your general requirements? What I see is a relatively verbose output for each file individually. Isn't it more convenient if you check if the files are formatted, that the program:

• If any files have issues, list files with issues, one per line, non-zero exit code
• If no files have issues, print a single line saying that no files have issues, zero exit code

If you could explain the concrete problems you encounter with concise output, that would be helpful. I'll need to understand the exact problems you encounter to be able to assess the proposal and find a good solution that does not impact other users negatively.

[DevTwilight]

What is needed is mainly to print what is currently happening during recursive directory execution.
For example, if I run:

gdscript-formatter --check path/to/folder

the formatter should log which file is currently being processed depending on the command.

Example:

Checking: addons/messagebox/core/tokenizer.gd

If an issue is found, it can then print:

Found formatting issue in addons/messagebox/core/tokenizer.gd

and after that print the actual errors, one error per line.

Example full output:

Checking: addons/messagebox/core/parser.gd

Checking: addons/messagebox/core/tokenizer.gd
Found formatting issue in addons/messagebox/core/tokenizer.gd
Line 18: incorrect indentation
Line 42: trailing whitespace

Checking: addons/messagebox/ui/dialog.gd

Checking: addons/messagebox/ui/theme.gd
Found formatting issue in addons/messagebox/ui/theme.gd
Line 7: unexpected blank line

If no issues are found, it does not need to print OK for every file. A single final message is enough, for example:

No formatting issues found.

The main idea is:

• show progress while processing files
• clearly associate errors with the current file
• make recursive execution easier to follow in CI and terminal usage
• avoid needing external shell loops only for progress visibility

So the request is not mainly about making output more verbose, but about making recursive execution transparent and easier to debug.

[DevTwilight]

Just checking if there are any updates on this feature request. Has there been any decision on whether this will be part of the formatter rewrite?

[NathanLovato]

Yes at least I'm definitely open to supporting a verbose output for logging purposes. I had taken a stab at it here, looking to overall compress the information, e.g. by avoiding repeating the file path: main...nathan/issue-227

Note that these parts of the output I would not support (always open to suggestions if there's a very strong use case/problem where you cannot do without this, but I'd prefer users use alternatives instead, or rely on the linter for aspects like these, to not add too much weight to the formatter code):

Line 18: incorrect indentation
Line 42: trailing whitespace

And to be transparent the priority for me is first making a great formatter, that is, that produces excellent output and that users don't need to think about or check. Other features are still on the table, just a bit more secondary/best effort (well, the entire formatter is best effort/a project mostly done in my free time) at least until I get a bit closer to this goal.