Describe the bug
With reference to these issues/PRs:
It would seem that the short term "fix" was to allow a config file path to be explicitly provided to turn off recursive crawling, and a longer term "TODO" for the next major was mentioned:
We should not recursively crawl for config files anymore if we find one in the root directory or next to the tsconfig.
I'm not sure either the short term fix or long term TODO fixes the following scenario:
(if it does, please let me know how)
Reproduction
Assume the following monorepo style layout:
packages/
package-a/ // this package does not use svelte or @sveltejs/vite-plugin-svelte
vite.config.ts
package-b/ // this package does use svelte and @sveltejs/vite-plugin-svelte
vite.config.ts
tsconfig.json // shared tsconfig.json file used by all packages
With svelte-check@4.5.0, running svelte-check from the project root runs successfully:
Loading svelte-check in workspace: [REDACTED]
Getting Svelte diagnostics...
svelte-check found 0 errors and 0 warnings
...and just to be sure that it is actually checking, if I deliberately introduce an issue it correctly errors:
Loading svelte-check in workspace: [REDACTED]
Getting Svelte diagnostics...
[REDACTED]/packages/package-b/components/Foo.svelte:5:6
Error: 'foo' is declared but its value is never read. (ts)
let foo = "";
</script>
====================================
svelte-check found 1 error and 0 warnings in 1 file
With svelte-check@4.6.0, running svelte-check from the project root now reports:
Error while loading config at [REDACTED]/packages/package-a/vite.config.ts
Error: No Svelte configuration found in vite config. Is @sveltejs/vite-plugin-svelte configured?
at ConfigLoader.loadConfig ([REDACTED]/node_modules/svelte-check/dist/src/index.js:40183:13)
Loading svelte-check in workspace: [REDACTED]
Getting Svelte diagnostics...
svelte-check found 0 errors and 0 warnings
Note that the error is complaining about package-a, which does not use svelte.
With svelte-check@4.7.0, running svelte-check --config packages/package-b/vite.config.ts from the project root suppresses the error.
However that only works because there is only one package in the repo that uses svelte.
How would this work if there was also a third package that used svelte, e.g.
packages/
...
package-c/ // also uses svelte and @sveltejs/vite-plugin-svelte
vite.config.ts
Would I need to run svelte-check separately for each package, passing the correct path to the vite.config.ts for that package?, e.g.
svelte-check --config packages/package-b/vite.config.ts && svelte-check --config packages/package-c/vite.config.ts
If we assume the long term TODO happens, note that my vite.config.ts files are neither in the root, nor are they adjacent to a tsconfig file, so it's not clear whether that would work here either.
Expected behaviour
In 4.5.0, running svelte-check at the root of a monorepo where individual packages may or may not use svelte would check successfully.
In 4.6.0 and later, that now errors unless a path to one of the package's vite.config.ts is specified, but it is not clear how this works when there are >1 svelte packages mixed with >1 non-svelte packages, each with their own vite.config.ts and a shared tsconfig in a parent directory.
System Info
- OS: [e.g. Windows] macOS
- IDE: [e.g. VSCode, Atom] VSCode
Which package is the issue about?
svelte-check
Additional Information, eg. Screenshots
No response
Describe the bug
With reference to these issues/PRs:
It would seem that the short term "fix" was to allow a config file path to be explicitly provided to turn off recursive crawling, and a longer term "TODO" for the next major was mentioned:
I'm not sure either the short term fix or long term TODO fixes the following scenario:
(if it does, please let me know how)
Reproduction
Assume the following monorepo style layout:
With
svelte-check@4.5.0, runningsvelte-checkfrom the project root runs successfully:...and just to be sure that it is actually checking, if I deliberately introduce an issue it correctly errors:
With
svelte-check@4.6.0, runningsvelte-checkfrom the project root now reports:Note that the error is complaining about
package-a, which does not use svelte.With
svelte-check@4.7.0, runningsvelte-check --config packages/package-b/vite.config.tsfrom the project root suppresses the error.However that only works because there is only one package in the repo that uses svelte.
How would this work if there was also a third package that used svelte, e.g.
Would I need to run
svelte-checkseparately for each package, passing the correct path to thevite.config.tsfor that package?, e.g.If we assume the long term TODO happens, note that my
vite.config.tsfiles are neither in the root, nor are they adjacent to atsconfigfile, so it's not clear whether that would work here either.Expected behaviour
In
4.5.0, runningsvelte-checkat the root of a monorepo where individual packages may or may not use svelte would check successfully.In
4.6.0and later, that now errors unless a path to one of the package'svite.config.tsis specified, but it is not clear how this works when there are >1 svelte packages mixed with >1 non-svelte packages, each with their ownvite.config.tsand a sharedtsconfigin a parent directory.System Info
Which package is the issue about?
svelte-check
Additional Information, eg. Screenshots
No response