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
While developing Wasp's support for schema.prisma file we agreed that it's best if we let users write whatever they want inside and we take it as the source of truth (as opposed to injecting config values on the fly which users don't see). This made sense since the users saw the config Wasp actually uses. Of course, we had to introduce validation for some fields Wasp depended on e.g. the url field has to beenv("DATABASE_URL") - the compiler throws an error if it isn't that value.
Idea
Since Wasp doesn't generate the tsconfig.json or the package.json but instead it uses the files as-is, Wasp apps can break if users change the config in weird ways or the config file can become outdated with the latest versions of Wasp. For example, if we figure out the new best values for the tsconfig.json then the user should update that file manually. If they don't, they have a broken IDE experience but Wasp compiler doesn't warn the user about it.
We should introduce some validation of the tsconfig.json and the package.json files:
there should be "wasp": "file:.wasp/out/sdk/wasp" in the package.json
"module", "target", "moduleResolution" fields in the tsconfig.json should have certain values
etc.
This way we are ensuring prerequisites for the Wasp app to run successfully and making the whole dev experience more robust. Users will know if they mess something up since the compiler will tell them.
The text was updated successfully, but these errors were encountered:
Sub issues
Added by @sodic:
tsconfig.json
- covered by Ensure "user" tsconfig.json files exists and is correct #939.package.json
- no issue yet.Backstory
While developing Wasp's support for
schema.prisma
file we agreed that it's best if we let users write whatever they want inside and we take it as the source of truth (as opposed to injecting config values on the fly which users don't see). This made sense since the users saw the config Wasp actually uses. Of course, we had to introduce validation for some fields Wasp depended on e.g. theurl
field has to beenv("DATABASE_URL")
- the compiler throws an error if it isn't that value.Idea
Since Wasp doesn't generate the
tsconfig.json
or thepackage.json
but instead it uses the files as-is, Wasp apps can break if users change the config in weird ways or the config file can become outdated with the latest versions of Wasp. For example, if we figure out the new best values for thetsconfig.json
then the user should update that file manually. If they don't, they have a broken IDE experience but Wasp compiler doesn't warn the user about it.We should introduce some validation of the
tsconfig.json
and thepackage.json
files:"wasp": "file:.wasp/out/sdk/wasp"
in thepackage.json
"module"
,"target"
,"moduleResolution"
fields in thetsconfig.json
should have certain valuesThis way we are ensuring prerequisites for the Wasp app to run successfully and making the whole dev experience more robust. Users will know if they mess something up since the compiler will tell them.
The text was updated successfully, but these errors were encountered: