Strict null checks#986
Conversation
EOL fixes
|
merged master (which contained multiple conflicting changes due to PRs' pile up). Should be good to go now. @DaelonSuzuka, this change touches multiple paths, so it would be great to get it in to avoid future complicated merges for this/other PRs. |
|
Thanks for updating. I'll try to get to this tomorrow (I want to at least skim the diff before I merge it). I'm not personally that interested in turning on these checks and I almost argued against it, but there's been an uptick in new contributors so it'll probably be worth the hassle. |
|
Thanks! I'm doing selfhosting for now, will update the PR if find any issues. Strict null checks for me is a great helper in validating my assumptions about the code. Definitely should help newcomers with understanding the code contracts. |
|
While I stand by my opinion that strict null is helpful in TS, I'm not the codeowner of this plugin. So please don't feel forced to change this based on my snarky remarks! |
|
I'm personally in support of this too, but it might be better to merge this after we tag a new release (just in case regressions occur as a result). |
|
Note:
This PR touches multiple points and is highly likely result into conflicts again. I'd prefer avoiding delaying this PR and increasing merge conflict chances (for other PRs too) again if possible. |
|
I do appreciate the opinions here. Strict null (and strict mode in general) definitely have benefits, they just also have (mental) costs that I didn't feel like paying when it was mostly me working on this. It looks like that's changing a bit (and I've gotten better at typescript) so I agree that it's time to turn this on. After this is merged, I'll look at strict mode too and see how much work that'll be. Thanks @MichaelXt! (and sorry again for the delays) |
From feedback on #936 by @HolonProduction