Rename ext-src to src in SDK
#2486
Conversation
| extCodeDirInSdkRootDir :: Path' (Rel SdkRootDir) Dir' | ||
| extCodeDirInSdkRootDir = [reldir|ext-src|] |
There was a problem hiding this comment.
We accidentally had two constants describing the same thing, so I removed this one.
| @@ -8,7 +8,6 @@ | |||
| "allowSyntheticDefaultImports": true, | |||
| }, | |||
| "include": [ | |||
| "vite.config.ts", | |||
| "./src/ext-src/vite.config.ts" | |||
There was a problem hiding this comment.
./src/ext-src/vite.config.ts isn't a thing since #1626, but we forgot to remove it from here.
These days, we're importing the user's config directly:
import customViteConfig from '../../../vite.config'
const _waspUserProvidedConfig = customViteConfigHm, should we perhaps add ../../../vite.config to the include array? Vite doesn't type-check anything anyway.
There was a problem hiding this comment.
I've put @ts-ignore about the import of user's Vite config because it's outside of the root (TS complained) - maybe that has changed? If not, then the include might not be necessary since it's ignored anyways?
There was a problem hiding this comment.
I've removed the @ts-ignore (you were right, it's no longer necessary since we're using references), but TS doesn't check anything anyway. It won't even report errors in web-app/vite.config.ts.
I think that's by design - the tsconfig.node.js is intended only for IDE support. We can therefore safely remove the user's Vite config.
One remaining question: What about users writing their vite.config.ts? Which tsconfig.json controls IDE support for that? At the moment, since root tsconfig.json doesn't target it, I think TS checks it with its default settings. @infomiho I created an issue for this: #2489
User's code is type checked as a part of the SDK (until we close #1718), meaning that TypeScript reports errors:
./node_modules/wasp/ext-srcinstead of ./src)../node_modules/wasp/tsconfig.jsoninstead of./tsconfig.json).Renaming
./node_modules/wasp/ext-srcto./node_modules/wasp/srcmitigates the first point - the errors now contain a path users would expect. It's not really the correct path as it's still under./node_modules/wasp, but it's similar enough.Before:
After: