Create a compiler replacement similar to tsc-silent for full ts compiler support

[nwetzel22]

I seem to be running into a few use cases where a tsc.js replacement may be necessary. For example, I'd like to use the --watch option, which I can't seem to integrate with loose-ts-check with a pipe operator. The tsc-silent project does this so I'm considering writing another tool base of off tsc-silent but its able to read in outputs from loose-ts-check. Any thoughts on this?

[Gelio]

Thanks for another issue. The problem with using loose-ts-check in a shell pipe is the lack of support for stream processing (#4). For it to even have a chance to work, we would have to implement the "Parsing errors one-by-one" variant. Then, I imagine we would use tsc --watch | loose-ts-check.

Using tsc --watch | cat is almost the same as just tsc --watch, just the colors are gone. This gives me this approach with loose-ts-check would work assuming the CLI does not wait for its stdin to be closed before it starts processing errors.

Let me know if you have other ideas how to get it to work with --watch mode, or if you have other use cases for which wrapping tsc inside loose-ts-check would be a must.

Personally, I'd prefer to only parse the output of tsc and not integrate loose-ts-check with it directly

Also, TIL about https://github.com/evolution-gaming/tsc-silent. I probably wouldn't have created loose-ts-check knowing tsc-silent exists. Both tools seem to do the same thing, as far as I can tell

[nwetzel22]

Thanks for the reference to #4. I like the sound of that. I think I might try to implement it. I went down the path of tailoring tsc-silent to work with loose-ts-check outputs. I have it working locally. However, I agree that parsing tsc output would be optimal. The tsc-silent package is great but probably a bit more prone to version errors as it recreates some internal tsc logic.

A few reasons I went with loose-ts-check over ts-silent:

1. loose-ts-check generates outputs whereas tsc-silent requires manual configuration. I prefer the former because it makes it easier to maintain the list of files/errors and prevents silencing of errors for new files going forward.
2. I wanted to avoid recreating logic with the tsc codebase.
3. tsc-silent seems to be fairly dormant and I had trouble running it as is.
4. I didn't know I would want/need the --watch option until yesterday.

One thing I do like about tsc-silent, though is that it allows for file/code pairs so that certain codes can ignored in certain files. I haven't needed this feature yet, but it sounds like it could be useful.

I'll see if I can get something working based on #4. Thanks again for the suggestion.

[Gelio]

Thanks for listing the reasons you went with loose-ts-check -- I appreciate it 👍

One thing I do like about tsc-silent, though is that it allows for file/code pairs so that certain codes can ignored in certain files. I haven't needed this feature yet, but it sounds like it could be useful.

I totally agree, it would be nice to be able to target some error codes just in particular files. That would be yet another issue we could work on

I'll see if I can get something working based on #4. Thanks again for the suggestion.

Awesome! Let me know if you need help

[nwetzel22]

I think I have #4 working with the ability to handle tsc -w. I need to write and verify some test and then I'll push up a PR for your review.