For any editor plugins, it only needs watch such file and update its problems panels once any change detected, thoughts?
Note the downside is that if you have some unsaved files, that won’t be detected but we can still report syntax errors for those unsaved files. This is not the most fancy way of doing error diagnostics, but it’s probably the most reliable way of doing it ?
It’s an addition to the normal output ? we’ll still see errors and warnings on standard output ?
That could be easier to synchronise the external annotator in my case.
how errors would be serialised in the log ?
Yeah. The difference being that what’s in the file is the latest run whereas in the terminal it’ll be streaming as usual.
The file will also persist after your build is done. Theoretically you can have other tools query it at a later time given that it’s not stale, but no promise for now.
Read-only diagnosis for editors is much more scalable. It means the editor itself (assuming you only have one open) doesn’t have to be the centralized point of building, aka you get to run your own bsb in the terminal, or have it as part of a larger build step without needing to negotiate with the editor to make sure you’re not stepping on each other’s toes, etc. It also means if you drag in a file from a different project, you don’t end up with some impedance mismatch of assuming that a single editor instance maps to a single project (e.g. you can show the errors from as many projects as you’d like in a single editor instance).
We do, but that part will be tackled differently. Unrelated to the feature above. Let’s focus on this issue first. Also, note that we’re not trying to reinvent the wheel; we’re only redoing the parts that should be solid. One big value proposition we have is a solid type system; for most users today, this isn’t even true if their primary interface to the type system is in-editor report, which is currently best-effort + mired by quite a few plugin-related problems. So that parts needs to be properly solved by ourselves. Type hints and autocomplete can defer to existing infra even.
That’s right. But it’s not like this particular feature would block what you’re asking for. We’re gonna postpone a real-time approach for now because we need a baseline of robustness. Also, it’s kinda hard to do real-time diagnosis while keeping soundness right now. Actually, to our knowledge, no language even offer the combination of soundness + real-time-ness in editor. At least we’re gonna check the first one now.
Yes, it’s the server that reads it. I have to draft up the description for how this should be done to avoid stale diagnosis as much as possible. This’ll be useful for other editors with different logic like IntelliJ, Sublime Text, etc. Feel free to keep watching the rescript-vscode repo’s docs.
After working on this post about build system changes, I realized that we can capture the warnings output without making any disruptive changes to clients. That means you can still have -warn-error as a fine grained control. The build system will just capture the warnings magically.
It’s a bit more work to restore such behaviors, but I will revert such changes to make user experience better.
Also I would like to take this as an example: the rescript maintainers have to make trade off from time to time, it’s in our best interest to make user experience better regardless of how much extra work needs to be done. Sometimes users may not have as much context as maintainers on the design space.