You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The react-ts template uses separate tsconfig files, one for everything in the src folder (tsconfig.app.json) and one that only includes vite.config.ts but might include other *.ts config files as well (tsconfig.node.json).
I struggle to understand why this is needed or recommended. As far as I understand, vite does not rely on a tsconfig to read the vite.config.ts. So, why not just include the vite.config.ts to the same tsconfig.json that is used for the source code or not include it at all in any tsconfig?
The only relevant aspect I see is type-checking the vite.config.ts. Of course some things allowed in browser-side javascript are not valid in node.js and might not be caught when simply using the same tsconfig as for the source code. But is that really the main advantage? And if so, would it be worth it?
I would be happy to get a good explanation why these multiple tsconfig files really make sense!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
The react-ts template uses separate tsconfig files, one for everything in the src folder (
tsconfig.app.json
) and one that only includesvite.config.ts
but might include other*.ts
config files as well (tsconfig.node.json
).I struggle to understand why this is needed or recommended. As far as I understand, vite does not rely on a tsconfig to read the
vite.config.ts
. So, why not just include the vite.config.ts to the same tsconfig.json that is used for the source code or not include it at all in any tsconfig?The only relevant aspect I see is type-checking the
vite.config.ts
. Of course some things allowed in browser-side javascript are not valid in node.js and might not be caught when simply using the same tsconfig as for the source code. But is that really the main advantage? And if so, would it be worth it?I would be happy to get a good explanation why these multiple tsconfig files really make sense!
Beta Was this translation helpful? Give feedback.
All reactions