WIP: YASNCB (Yet Another Strict Null Checks Branch)

[corasaurus-hex]

What has Changed?

This turns on strictNullChecks in TypeScript and fixes all the remaining issues in the codebase that were preventing us from turning this setting on.

My Calva PR Checklist

I have:

• [x] Read How to Contribute.
• [x] Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• [x] Made sure I have changed the PR base branch, so that it is not published. (Sorry for the nagging.)
• [ ] Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
• [ ] Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
• [x] Added to or updated docs in this branch, if appropriate
• [ ] Tests
  • [ ] Tested the particular change
  • [ ] Figured if the change might have some side effects and tested those as well.
  • [ ] Smoke tested the extension as such.
  • [ ] Tested the VSIX built from the PR (so, after you've submitted the PR). You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test.
• [~] Referenced the issue I am fixing/addressing in a commit message for the pull request.
  • [~] If I am fixing the issue, I have used GitHub's fixes/closes syntax
  • [~] If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.
• [~] Created the issue I am fixing/addressing, if it was not present.
• [~] Formatted all JavaScript and TypeScript code that was changed. (use the prettier extension or run npm run prettier-format)
• [~] Confirmed that there are no linter warnings or errors (use the eslint extension, run npm run eslint before creating your PR, or run npm run eslint-watch to eslint as you go).

Ping @pez, @bpringe, @corasaurus-hex, @Cyrik

[PEZ]

I found this in the noise where the integration test broke:

UNRESPONSIVE extension host: 'betterthantomorrow.calva' took 100% of 5100.624ms, saved PROFILE here: 'file:///tmp/exthost-19cc55.cpuprofile' [ { id: 'betterthantomorrow.calva', total: 5100381, percentage: 100 } ]

https://app.circleci.com/pipelines/github/BetterThanTomorrow/calva/5020/workflows/5edc3168-da3a-4cf8-ab29-02c887c079c0/jobs/21872?invite=true#step-104-114

Before that I also find:

[137:0501/213503.162639:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

Which I am not sure if we usually see or not, but if not maybe it could be the cause of the timeout.

Anyway, those UNRESPONSIVE extension host: 'betterthantomorrow.calva' took 100% of 5100.624ms messages I sometimes see in the dev console when I have introduced some change causing Calva to go into a spin while activating.

I would see if I could run these tests locally. If you haven't before, it's surprisingly easy:

0. Quit VS Code Insiders if you have it running
1. In an integrated terminal of regular VS Code: npm run integration-test

[corasaurus-hex]

I ran it locally and profiled the code to find where it's stuck. I just need to figure out why it's stuck. I have the last known working commit sha for integration tests but it's not clear why it's broken by the following commit

[PEZ]

Which commits does the bisect give you? Maybe we can see what could be the cause with more eyes on it.

[PEZ]

Is it here?

https://github.com/BetterThanTomorrow/calva/pull/1703/commits/fcf14e04179ab763d5b3e601b64b5a679f08b2fd

If so, that is still a bit opaque to me. 😄 I don't know what the implications are for enabling strict null checks.