Civet
Civet copied to clipboard
DanielXMoore
LSP wont exclude dist folder without tsconfig.json
Problem Description
I started with a basic civet install with esbuild. But because the src folder didn't contain any .ts files the TS LSP complaint as follows:
No inputs were found in config file 'e:/Projects/test/ts-civet/tsconfig.json'. Specified 'include' paths were '["src"]' and 'exclude' paths were '["dist"]'.
So following my instinct i renamed the tsconfig.json to tsconfig.civet.json, Also supplying this new file to esbuild config. But this lead to a new issue where Civet LSP would complain now because it's not ignoring the .js files compiled in the dist folder.
I guess a good alternative would be to let user define some kind of external config if tsconfig.json is not found, like maybe a civet.config.json or something similar
In the first situation, are you using the Civet LSP and the TS LSP? Normally you should disable the built-in TS LSP of VSCode, and just use the Civet plugin. Does it work in that case?
In the first situation when using filename tsconfig.json the error output is from TS LSP so disabling it removes the error. But it is not the best solution as you have to disable a builtin vscode plugin manually by creating a settings.json file in this workspace. Ofcourse you wouldn't disable typescript globally.
The root cause is TS LSP automatically runs if it finds the tsconfig.json in root of a workspace. If i was able to use a different filename with Civet LSP, TS LSP wont even start because
- it would not find tsconfig.json at root of workspace
- it wont find any .ts files in the workspace
Having an alternative tsconfig.json that Civet detects and TS doesn't is a good idea! That way I won't have to keep enabling and disabling extensions per workspace. I'll try to get to this the next time I'm improving the LSP.
Instead of yet another file, we could include it as part of the civetconfig file, perhaps under a typescript key?
Instead of yet another file, we could include it as part of the civetconfig file, perhaps under a typescript key?
Yeah, this one is probably better. We already have too many config files these days xD