Open m2u-84 opened 1 month ago
Hey @m2u-84!
Thanks for clearly outlining the requirements.
When the team begins working on this, I believe it’s best to first configure the formatting at the app level, storing the configuration in the app’s cache. Once we've made solid progress, we can explore the possibility of defining a schema that would allow this configuration to be included in the bruno.json file, enabling formatting at the collection level.
Considering the large number of features and issues still on our plate, it might be a while before we get to this.
I have checked the following:
Describe the feature you want to add
Since Bruno collections are based on structured text files and meant to be committed to Git or other version control systems, it would be awesome if Bruno respected the popular and widespread EditorConfig format for code formatting preferences. Right now spaces are always used as indentation characters with a depth of two per level and empty lines in indented blocks keep the spaces in place instead of removing them.
Many repos use various (automatized) solutions to guard formatting rules or even enforce them based on EditorConfig settings. It would be really great if Bruno also auto-applied those rules (or applied them if its own settings told it to). Otherwise there is a constant back and forth between formatters and Bruno, leading to unnecessary and tedious Git changes that you either have to apply or discard all the time. You could of course configure an exception for directories with Bruno collections in it, but then again it is nice to have consistent formatting rules across a whole repo and that’s why EditorConfig exists in the first place.
Here are the major EditorConfig properties and supporting all of these would actually make sense imho:
indent_style
: "tab
" | "space
" whether to use tabs or spaces as indentation charactersindent_size
:number
| "tab
" number of spaces to use per indentation level or keyword "tab" to derive this number from thetab_width
property’s valuetab_width
:number
width to be used for tabs (usually not required becauseindent_size
can be used for that)end_of_line
: "lf
" | "cr
" | "crlf
" which style of line endings to usecharset
: "latin1
" | "utf-8
" | "utf-8-bom
" | "utf-16be
" | "utf-16le
" charset to be used for writing / reading files – currently seems to be utf-8 for Bruno files, so that is probably already fine as it is and is rather nice to havetrim_trailing_whitespace
: "true
" | "false
" whether whitespace (apart from linebreaks) should be removed on the end of each line – this would also help if you don’t want any leftover spaces / tabs in otherwise empty linesinsert_final_newline
: "true
" | "false
" whether to include a final newline at the end of each file – also maybe nice to haveroot
: "true
" | "false
" flag to mark an EditorConfig file as child or parent (root) configSupporting the various matching patterns for rule blocks besides the global ruleset might be a little tricky. Those can take various forms, e.g.:
[project_root/bruno/]
path specific rulesAlso merging rules from root and child configs could become a challenge. To keep the complexity of this feature low, it might be necessary to restrict EditorConfig support to e.g. only respecting root configs and only with blocks with specific paths without glob patterns (at least for now).
Ideally it would be configurable via Bruno’s GUI whether EditorConfig files should be searched for and respected. This could happen on the application-wide config level or per project / collection. Since EditorConfig files can be nested across directory structures, it might make sense to optionally define a max depth to look for those files upwards from the current collection’s location. As soon as traversing up the path hits a
root = true
config, search could be stopped of course.Mockups or Images of the feature