Agreed. I was imagining a civetsc CLI tool (or something like that) that runs TypeScript on the transpiled files, following tsconfig.json (or maybe even tsconfig.civet?).

Perhaps it should be a second bin for the main Civet package. Or perhaps it should be its own NPM package, given that it would have a typescript peer dependency?

runs TypeScript on the transpiled files

That may not be a great idea. Ideally we'd non-interactively do what the lsp client already does so that any errors etc. have correct source line numbers.

@STRd6 Are you open to bin/civettsc (or maybe just civetc) ? I think keeping this outside may be a maintenance burden because I think tsserver integration is still early and keeping the two in sync may need more work.

I agree that this should be part of this repo (but maybe separate NPM package), and wyen I said "run TypeScript" I meant the same thing as the LSP (not running tsc).

Having an additional civetc build product in bin makes sense. I also agree that making use of the same TSServer wrapping is important so that the editor error messages match the cli error messages exactly. I'm in support of anyone who wants to work towards this.

Ok cool. Looks like everyone is on the same page then.

I can take this up mid next week.

Feel free to refactor out the TSServer wrapping from lsp into a shared lib if it makes things easier.

An update on this: if you use Vite, Rollup, ESBuild, or Webpack to build your Civet code, our new unplugin for these systems now has a typecheck: true option that will do typechecking. So we now have a reasonable way to do type checking in CLI!

We should try to extract the typecheck: true feature from the unplugin into a module that the CLI could directly call. This would still require installing typescript locally (or globally?), but would make it easy to integrate into the existing CLI with a command-line option like civet --typecheck or civet -t.

Surely the bin should be called tscivet… or tscvt?

I guess it's a tradeoff on whether to have just one bin or multiple. I don't have a strong feeling, but most of the code would be shared with the CLI so I think allowing for civet -t at least makes sense. We could also add an alias of tscivet or civetsc if we want.