Add JSON output formatting
[ ] Polish a JSON output [ ] Add tests for the change. [ ] Add any appropriate documentation. [ ] Run checks and CI
i wonder if a tag --json is better or a tag in the form --format json to open for other types of formatting later
Another approach to making this a CLI argument would be to provide a Python API for running Import Linter (something I've been meaning to do anyway) with a structured return value. Then a plugin could wrap that (without needing to parse JSON). Any thoughts on that approach?
That would be pretty nice, but it doesnt solve all the problems ; vs code extensions for example have to be done using JS and node JS ; i think it would be nice in a second time, i would be happy to help you do that
But you're extension is going to have to run some Python somehow, right? So perhaps a good approach would be to for you to write the wrapper Python CLI in a different package, that would then call Import Linter's Python API and transform the data how you need it to be. That would give you more control over tailoring it specifically to the extension, while providing a more generally useful tool in Import Linter.
I've been meaning to add a Python API anyway so it might be less work for you, too!
Usually you run command lines and get the output i think, but yeah that could do it ; it would be especially helpful, since the extension might not want to rerun everything everytime ; have you ever worked with pydantic ? it could be really helpful : everything would work as normal but JSONification of objects(like report etc..) would be much simpler ; i think ill start with just the json output to familiarize with the codebase, i'll look into the API part after it
i think this works, I'm having trouble with how to make the tests, i don't know what level of testing you want(it should be a formatting of the same results in normal mode)
i think your iteration is quite right, no data is lost or formatted too much ; maybe add the time of the contract run ? i dont know exactly where to gather the version number
maybe add the time of the contract run
I don't think this is necessary, unless you have a use case in mind?
i dont know exactly where to gather the version number
This can just be hardcoded as 1, maybe as a constant. If we change the schema we'll bump the version number.