You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lots of formatters have extra config users may want to pass, and creating a top-level flag for each one will get cumbersome. We should consider a generic mechanism for passing flags through to formatters.
Factors to consider:
These should be attached to the fine-grained formatter name, not the language, because we don't want to accidentally pass them to a different formatter that doesn't support them when the user switches formatter.
Some might conflict with default flags. For instance, a user might want to pass --type to js-beautify and find that it conflicts with the --type flag we already pass by default.
Most config would be per-path rather than global preferences. For instance, a user will want to configure an --aosp flag when working on Android Java, but then be surprised if it's applied to other Java code they're working on later.
If possible, these config options should live in some project-local config file like .clang-format or .editorconfig, not something codefmt-specific, and codefmt should just try to be smart about detecting and not conflicting with such config where appropriate.
The text was updated successfully, but these errors were encountered:
Yeah, per-path config is one concern (particularly w/ the --aosp example), and I have a few other minor concerns: they might need to override flags we're passing by default (like --type in the example above), and shell escaping gets weird (which you worked around for google-java-format, I guess).
Lots of formatters have extra config users may want to pass, and creating a top-level flag for each one will get cumbersome. We should consider a generic mechanism for passing flags through to formatters.
Factors to consider:
--type
to js-beautify and find that it conflicts with the--type
flag we already pass by default.--aosp
flag when working on Android Java, but then be surprised if it's applied to other Java code they're working on later..clang-format
or.editorconfig
, not something codefmt-specific, and codefmt should just try to be smart about detecting and not conflicting with such config where appropriate.The text was updated successfully, but these errors were encountered: