Code Health Devlog 3 - Releasing
Published on
Previous Devlog Recap
In the previous devlog, I covered a simple workflow for actioning code smells, testing across different repository types, and a design simplification. Now I am ready for my first minor release to the VSCode marketplace. However, there are still multiple steps to get there.
Checklist
- Create a publisher profile.
- Open-source the repository.
- Setup CI/CD.
Create A Publisher Profile
In order to publish an extension to the VSCode marketplace, you are required to create a publisher profile through the publisher management page. At a minimum you need a name; however, I wanted to create a profile that's consistent with my website.
For this reason, I created a logo in Figma with the same typeface and colours, included a description and relevant links.
Linking my extension to my profile also required setting the publisher property in the package.json to my publisher id.
Open-source The Repository
The vast majority of extensions on the VSCode marketplace are open-source, and that's why I'm choosing to open-source mine. Additionally, building in public encourages me to hold myself to a higher standard.
The first step in open-source is to choose a license and add the LICENSE file to the root—I went with the popular MIT license.
Second, I populated the repository, icon, category and keywords properties of the package.json accordingly.
Third, I needed a clear README.md to provide people relevant information about the why, what and how of the extension.
This includes a short hook and demo, compatibility requirements, getting started and features.
Finally, I need to maintain a CHANGELOG.md with the history of changes, which I'll go deeper on in the next section.
Setup CI/CD
Before I can automate the continuous delivery and deployment of my extension, I wanted to test it locally.
That can be done by packaging the extension with a command from the vsce CLI tool (vsce package),
which produces a .vsix file you can upload via the Install from VSIX... button in the extension tabs meatball menu.
This immediately showed me that I needed to make sure the binaries (esbuild, fallow and oxlint) are included in the packaging process.
Getting that to work required a few things, adding the supportedArchitectures configuration to pnpm,
adding the different OS binaries to bundledDependencies in package.json, and using the --target flag with the package command to create the platform-specific files.
After a successful test of the file, I was ready to publish.
That requires generating a global PAT token or Microsoft Entra-ID authentication. The latter is recommended; however, a PAT was quicker for my first publication.
Now I can publish with vsce login <publisher-id>, provide the PAT, then vsce publish --packagePath <target-file-path>.
I turned this process into a small script that does the pre-flight checks, packages, and publishes for reuse. The final step is to turn this process into continuous delivery and deployment.
I decided to use the release-please-action from Google, which uses conventional commits to determine what the semVer bump should be.
When pushing to main, it automatically creates a PR that updates the version in package.json,
and updates the CHANGELOG.md with the information gathered from those conventional commits.
When that PR gets merged back to main, the publish job will kick off and run the script I created earlier.
Reflections
One of the great things about finding an idea for a personal project is that it gives you the chance to get hands-on learning with things you don't usually get the chance to do in a regular engineering job. For example, CI/CD is usually already set up, and rarely touched, unless minor tweaks are needed as a project evolves.
Creating devlogs about the chaotic process of development was really useful for staying on track and clarifying my thoughts.
I experimented with the "design it twice" concept from The Pragmatic Programmer throughout this project with Claude and found it really useful on a micro scale. Applying the concept honestly felt like a nice balance of retaining the joy of craftsmanship while moving fast with my robot thinking partner. LLMs are microwaves, I am the chef.
Overall this process was really enjoyable. If anyone wants to utilise the tool, you can find it by searching for codehealth.js in the VSCode extension tab. If you find bugs or have ideas, report an issue on GitHub!
https://marketplace.visualstudio.com/items?itemName=kaitlynparsons.CodeHealthJS