-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enables strict null checks in SDK #2360
Conversation
waspc/data/Generator/templates/sdk/wasp/auth/forms/internal/common/LoginSignupForm.tsx
Outdated
Show resolved
Hide resolved
const { data: task, isLoading } = tasksCrud.get.useQuery({ | ||
id: parseInt(id, 10), | ||
}); | ||
const { id } = useParams<{ id: string }>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR, but a quick fix since id
is of type string | undefined
.
waspc/data/Generator/templates/sdk/wasp/client/operations/queries/core.ts
Outdated
Show resolved
Hide resolved
@@ -1,9 +1,9 @@ | |||
{{={= =}=}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've started to work on enabling strict null checks while working on env variables, so these are some changes I left from that effort - env
-> nodeEnv
since I imagined that the import of env vars would look like import { env } from 'wasp/server'
waspc/data/Generator/templates/sdk/wasp/client/operations/rpc.ts
Outdated
Show resolved
Hide resolved
18f9fd0
to
a509762
Compare
username: process.env.SMTP_USERNAME!, | ||
password: process.env.SMTP_PASSWORD!, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is throwing all kinds of errors for me. I tried to build the server with TypeScript (npx tsc
in .wasp/out/server
) and it failed.
Does this work for you normally (I'm guessing it does, because you wouldn't know these types needed changing if it didn't).
I probably messed something up because it also fails on older versions of main. If everything's normal for you, I'll dig in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If npx tsc
fails on server output on main
, I'd say this is a matter for a different PR. Running it on main
gives me:
...
Found 10 errors in 5 files.
Errors Files
1 src/auth/providers/config/discord.ts:13
5 src/auth/providers/config/email.ts:34
1 src/auth/providers/config/github.ts:13
1 src/auth/providers/config/google.ts:13
2 src/webSocket/initialization.ts:17
while running it on this branch gives me:
...
Found 18 errors in 8 files.
Errors Files
1 src/auth/providers/config/discord.ts:13
5 src/auth/providers/config/email.ts:34
1 src/auth/providers/config/github.ts:13
1 src/auth/providers/config/google.ts:13
2 src/auth/providers/email/login.ts:64
3 src/auth/providers/email/resetPassword.ts:45
3 src/auth/providers/email/signup.ts:160
2 src/webSocket/initialization.ts:17
The new errors are fixed here: 630c107
I'd do it like this:
- create a new issue to add
npx tsc
on the built server in the CI - create a new PR that add
npx tsc
on server in the CI - fix the remaining 10 errors in that PR
waspc/data/Generator/templates/sdk/wasp/auth/forms/internal/common/LoginSignupForm.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I'm approving.
Just make sure you cover these before merging:
- Enables strict null checks in SDK #2360 (comment)
- Enables strict null checks in SDK #2360 (comment)
- Enables strict null checks in SDK #2360 (comment)
- Enables strict null checks in SDK #2360 (comment)
- Enables strict null checks in SDK #2360 (comment)
I've fixed my part, left some comments explaining it, and gone through at your fixes.
I didn't run the e2e tests yet because you'll probably make a few more changes.
|
||
getJobScheduleData = | ||
maybe | ||
(object ["isDefined" .= False]) | ||
( \schedule -> | ||
object | ||
[ "isDefined" .= True, | ||
"cron" .= J.cron schedule, | ||
"args" .= getJobScheduleArgs (J.args schedule), | ||
"options" .= getJobSchduleOptions (J.scheduleExecutorOptionsJson job) | ||
] | ||
) | ||
getJobScheduleArgs = | ||
maybe | ||
(object ["isDefined" .= False]) | ||
(\args -> object ["isDefined" .= True, "json" .= Aeson.Text.encodeToLazyText args]) | ||
|
||
getJobSchduleOptions = | ||
maybe | ||
(object ["isDefined" .= False]) | ||
(\options -> object ["isDefined" .= True, "json" .= Aeson.Text.encodeToLazyText options]) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just please double check we didn't break anything (does the e2e test look alright to you).
We could add a few "complicated" job declarations to the job e2e test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested the scenarios:
- having args, not having args
- having options, not having options
- having the root level schedule, not having schedule
The resulting code looks OK to me 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crap, I forgot about this thing: #2360 (comment)
I have to revoke approval (sorry for the tease). We should either:
- Fix all the errors and add the server build step to the CI (best option, but longest)
- Not introduce new errors and create an issue for the old ones and building the server in the CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
This PR enables
strictNullChecks
option in the SDKtsconfig.json
.We want to enable this option to make sure Zod schemas are working properly before we start using them for env variables validation.
Left to do
@ts-ignore
and a TODO for things that need more workUsing
@ts-ignore
is not that problematic since it will unblock us for using Zod schemas, but also explicitly mark parts of the code base that need some work. This work was still needed before this PR, but it was implicit.