Project Details
I chose the same project I chose during the 0.3 release, named blockly-samples for the 0.4 release, essentially to build upon my knowledge. Initially, I searched for other projects to contribute to, to expand my knowledge but a couple of things pulled me right back to this project. One is the way they do code reviews. Their PR reviews are prompt and contain deep insights on how to make code changes and the impact of those code changes. Another being it's a Google project after all LOL. I'd learn so much from how their developers write code, considering they hire the best of the best engineers/developers in the field. After assessing a couple of these benefits I decided to continue my journey with this project for 0.4 release.
Plan/Approach
As mentioned earlier, I wanted to build upon my knowledge for this project so I did just that. I did a big PR in 0.3 outlined here which was related to fixing linting issues for TypeScript (TS) code. That PR was a mix of linting plus barely scraping the surface of TS code where most of the ESLint warnings were about fixing JSDoc comments and just a mere 2 warnings were about fixing types in TS. Even though I didn't directly add or update the TS code in the project, I regularly interfaced with it during the 0.3's PR which gave me enough confidence to dive deeper into writing TS code for an issue. This was going to be the first time I contributed directly to writing TS code and coupling it with a project of a scale this big, so it was a big deal for me after all. Even though TS is a wrapper over JS we can give it the benefit of the doubt that it won't take that much of an effort from my side to write TS code compared to Go code let's say (because I know nothing about Go), however, that doesn't mean it'll be a smooth sailing ride for me just because TS and JS are brothers. Whatever it had to throw at me I was ready for it.
I started searching for a couple of issues within the project specifically related to TS. The idea was to do feature requests, a bit of a bigger outreach from my end towards the project rather than doing small PRs with good-first-issue tags. And that's when I stumbled upon these 2 issues namely Enable strict mode for workspace-backpack and Enable strict mode for workspace-search. After reading the description of issues it became clear that they fit well with the scale of the PR that I was looking for. Building upon my knowledge from the previous release, these 2 issues specifically targeted enabling strict mode for TS code within 2 plugins namely workspace-backpack -- allows a user to save current blocks on the workspace to a backpack and workspace-search -- allows a user to search for items present within the blocks on the current workspace.
As per TS documentation website a strict flag enables a wide range of type-checking behaviour that results in stronger guarantees of program correctness. Turning this on is equivalent to enabling all of the strict mode family options, which are outlined below:
noImplicitAny: disallows implicit any types.
strictNullChecks: disallows nullable values.
strictFunctionTypes: enforces stricter function types.
strictBindCallApply: enforces stricter bind, call, and apply methods.
strictPropertyInitialization: enforces stricter property initialization.
alwaysStrict: always emit use strict directive.
Both the issues mentioned, enabling strict mode for TS code would result in build time issues like adjusting types, adding checks for null or undefined, or making other fixes that needed to be addressed allowing me to directly write TS code, the first of two goals. Besides, this also allows me to penetrate deeper into the project's codebase which is the second of two goals for this release. I'm looking forward to successfully achieving both of these goals in this release.
Top comments (0)