Request for Enhanced JSON Output in Reporter

[GiladShoham]

In the default reporter/output, line and column numbers are displayed directly, while in the JSON output, only the offset is returned. This requires users to manually calculate the line and column numbers.

Additionally, the default formatter provides valuable context by displaying the line of the error along with the preceding and following lines. However, users relying on the JSON output currently need to compute this context themselves.

It would be greatly beneficial if this information were included in the JSON output as well.

Thank you!

[DonIsaac]

I can see the use case for line/column numbers, but could you please elaborate on how code snippets would be beneficial?

We mostly use JSON output for VSCode integration, where code snippets would not be used. Do you have a different use case in mind?

[GiladShoham]

Thanks for your response @DonIsaac
Yes, I'm running oxlint from a node script (will publish an OSS with a full node.js wrapper soon)
and store the results somewhere in my db, later on, I'm showing the results on a web application.
so I want to show it on the app with the code snippet.

[DonIsaac]

I've been thinking that we should expose the linter as a crate and/or NPM package for better integration with other tools (e.g. bit, or hopefully even Next.js). How would you feel about consuming linter output via a crate, modifying it to suit your needs, and then consuming it via NAPI?

This has the following advantages:

1. Oxlint could better integrate with other tools in general, without having to modify its output to meet the specific needs of every consumer
2. Our json output format could stay light, which keeps transfer costs between our LSP server and VSCode/any other LSP client fast and lean

[GiladShoham]

Consuming it via a crate with a npm package would be great for me.
I would help you build it but I'm not a rust expert (maybe someone else from my team can help a bit).
I'm also fine with a special flags to get more info like --json --verbose or something similar then later move to a npm package.
In general working with a child process calling to a cli is less optimal for me as it slower and give me less control and more errors prune.

[GiladShoham]

Another thing that I see missing in json format

• duration
• number of files
• number of rules
• number of threads

for example:
with default:

Finished in 10ms on 3 files with 90 rules using 10 threads.
Found 0 warnings and 0 errors.

with json:
[]

[Sysix]

Hello 👋
I worked the last days on the output for oxlint. Now everything requested should be possible with the current architecture.
For getting start/end column/line you need to use Info::new(diagnostic). See how used in in github format:
https://github.com/oxc-project/oxc/blob/ef55e7c37c226925108b4d145909a82d9ae730c2/apps/oxlint/src/output_formatter/github.rs

Our json output format could stay light, which keeps transfer costs between our LSP server and VSCode/any other LSP client fast and lean

the language server is using oxlint native with rust. and LSP is its own protocol with format. No need to check for it.

[GiladShoham]

@Sysix thanks,
Having this info in the json output would be really great :)