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
It appears that sveltekit isn't as strict during dev as during build.
See the silly mistake i made in the snippet below. When in pnpm dev, this endpoint magically works and there is no problem with me not declaring the variable first. However, when you pnpm build > pnpm preview, the same script will cause a runtime error.
exportfunctionget(){test=123return{status: 200,body: {
test
}}}
Describe the proposed solution
Normalizing strictness. Both environments should throw an error.
Alternatives considered
Keep this as is since it indirectly serves as a good reminder to check the sloppiness of the code you've written so far.
Or maybe run the endpoints in strict mode like after build? Not sure if that is possible though.
Importance
would make my life easier
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Wouldn't say it's a duplicate since the previous one was closed and we ought to do something about it.
I used to think that this was caused by strict mode not being present in dev mode, but now I remember modules should be strict by default right? Might be something weird going on there because of pre bundling otherwise the solution would be a lint rule I guess.
UltraCakeBakery
changed the title
Always force the declaration of variables before assignments in endpoints
Consistent strictness
Jun 27, 2022
Describe the problem
It appears that sveltekit isn't as strict during dev as during build.
See the silly mistake i made in the snippet below. When in
pnpm dev
, this endpoint magically works and there is no problem with me not declaring the variable first. However, when youpnpm build
>pnpm preview
, the same script will cause a runtime error.Describe the proposed solution
Normalizing strictness. Both environments should throw an error.
Alternatives considered
Keep this as is since it indirectly serves as a good reminder to check the sloppiness of the code you've written so far.
Or maybe run the endpoints in strict mode like after build? Not sure if that is possible though.
Importance
would make my life easier
Additional Information
No response
The text was updated successfully, but these errors were encountered: