Better support for .editorconfig in shfmt

[marcinrogacki]

Hi. I had some troubles to setup the formatter and ended up learn inconvenience of shfmt used via stdin.

It's easy for a single script, however I believe it would be great to document it

$ cat bashly-settings.yml
formatter: shfmt --filename mycli
$ cat .editorconfig
[mycli]
indent_size = 4

Here is how to apply .editorconfig for multi files. The dummy filename can be used, since the [bin/*] glob will match it. That allows format several scripts defined in bashly.yml e.g. bin/mycli, bin/mycli2, bin/mytool, bin/myscript. Maybe is it worth to support a file name variable formatter: "shfmt --filename %{target_script}"?

$ cat bashly-settings.yml
target_dir: bin
formatter: shfmt --filename bin/dummy
$ cat .editorconfig
[bin/*]
indent_size = 4

Unfortunately I don't see an option to have separate rules per generated script, however I believe it's an unlikely case to happened.

Thanks for creating the bashly, cheers.

[DannyBen]

Linking the formatter documentation here for reference.

I understand the use case, but I am not comfortable expanding the formatter interface or recommending this pattern as part of Bashly's generation workflow.

My reasoning is:

1. Bashly's generated code is already designed to be shfmt- and ShellCheck-compliant, using Bashly's established two-space indentation convention.

2. If someone wants bashly generate to also reformat their own merged code, formatter: external pipes the generated script through Bashly's predefined shfmt command.

3. If different formatting rules are required, the formatter setting already accepts a custom command, including any desired shfmt flags. For the example in this discussion, this can be as simple as:

   formatter: shfmt --case-indent --indent 4

4. The custom formatter has an intentionally small contract: it receives the generated script on stdin and must return the formatted script on stdout. I consider this an extension point at the edge of Bashly's responsibility, rather than the beginning of a configurable processing pipeline.

5. Adding tokens such as %{target_script} would blur that contract. The target file is written only after formatting, so exposing its path could suggest that formatters may read or modify that file directly. Commands using the path as input, or using options such as shfmt --write, would not behave correctly within the current stdin/stdout flow.

6. If formatting depends on the actual output path, uses different rules for different generated files, or requires additional processing stages, that is better handled after generation by a build script or task runner. For example:

   bashly generate && shfmt --write bin/mycli

For projects that already use EditorConfig and only need one shared rule for all generated scripts, the workaround shown here remains compatible with the existing contract:

formatter: shfmt --filename bin/dummy

In that form, --filename supplies metadata for EditorConfig matching while shfmt still reads stdin and writes stdout.

I would therefore prefer to keep Bashly's formatter as a simple stream transformation. More elaborate, file-aware post-processing belongs in the surrounding project workflow; Bashly's settings should not grow into a build-system or pipeline configuration.

[marcinrogacki]

Thank you for quick replay, especially for point 5 (and 4). Indeed it would be misleading.

[DannyBen]

and as a side note - if you don't already have your favorite task runner, check out opcode.

I am using it in many of my projects, to define tasks like this:

# op.conf
build:
  op generate
  op man

man: bashly render :mandoc doc

generate: bashly generate "$@"

check:
  op shellcheck
  op shfmt
  op test
  green ALL CHECKS PASS