-
Notifications
You must be signed in to change notification settings - Fork 76
feat: add json formatter #336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@Kashugoyal Thanks for the PR - please address all Golang-CI comments and fix failing unit tests |
208ce3a
to
dcf1526
Compare
dcf1526
to
2061a41
Compare
@kehoecj PR is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as advertised but needs some architectural changes
groupOutputPtr = flag.String("groupby", "", "Group output by filetype, directory, pass-fail. Supported for Standard and JSON reports") | ||
quietPtr = flag.Bool("quiet", false, "If quiet flag is set. It doesn't print any output to stdout.") | ||
globbingPrt = flag.Bool("globbing", false, "If globbing flag is set, check for glob patterns in the arguments.") | ||
formatPtr = flag.Bool("format", false, "Format all supported file types in place. Only json is supported currently.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking ahead to when multiple types are supported:
- Users need to be able to specify which config types they want to format. All can be the default but needs to be configurable
- Need to think about how we'll allow users to specify formatting settings. I know you had identified it in future work but I think it needs to be part of this PR. I don't think we'll be able to specify this on the command line, will probably have to be a config file (or multiple config files)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do flags like --format-all
, --format-json
, --format-yaml
, etc?
format-xxx
to enable formatter for a specific file type,
format-all
for all
format-config
to follow config specification, e.g. --format-config ./formatter_config.json
For the settings specification, it can be a JSON file with top level keys for file types.
e.g.:
"formatters": ["json", "yaml", ..],
"json": { "indent": 2},
"toml": {..}
...
The implementation for the config would be a larger change and maybe we can address as a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about passing options to -format
? Example: -format=all
OR -format=json,yaml,ini
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the settings JSON - that makes sense to me. Agree that would be part of a larger change later, just wanted to ensure the initial design didn't constrain the later implementation
if ShouldFormat { | ||
if exitCode, err := formatFiles(filesToFormat); err != nil { | ||
return exitCode, fmt.Errorf("unable to format files: %w", err) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The design of this could be refactored to be more efficient:
- Call the formatter in the initial foundFiles loop rather than adding it to a list then looping again.
- The formatFiles function logic should be moved down into the formatter rather than in the CLI
github.com/magiconair/properties v1.8.10 | ||
github.com/pelletier/go-toml/v2 v2.2.4 | ||
github.com/stretchr/testify v1.11.1 | ||
github.com/tidwall/pretty v1.2.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think we should be using this package. It appears to no longer be maintained as it hasn't been updated in 3+ years. Implementation should be changed to use the standard library's Marshall Indent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it is possible to ensure retention of the JSON field order if we parse JSON bytes and use MarshallIndent to generate formatted output. If this is not a requirement, we can use it then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the JSON spec it shouldn't matter:
An object is an unordered set of name/value pairs
We can specify that order of elements will not be preserved in the documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a user I would not like it if a formatter changed the order of my fields in the JSON file. But if that is alright, I don't mind switching to MarshalIndent.
I will make that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Kashugoyal what would you suggest as an alternative?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually after doing some research I found this method called Indent in the built in golang JSON library. Although it does not explicitly guarantee order preservation but when I looked into its implementation, it is very similar to what "pretty" does.
I am going to try that instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks promising!
Resolves #159
This PR:
Left for Future work: