Forcing Good Code Practices

Lucky you, reader! You get a twofer today. I worked on this mini-project in my NPM monorepo alongside my Bun updates except, Bun was not used here. Actually, I really wanted to switch over to Bun for this repo, but there's just a few features that make the switch really stupid.

Quick Sidebar

One thing that is not negotiable for me is to publish my packages with provenance. Actually, I don't really understand the importance of that, but I know that it has to do with good cybersecurity practices and this is honestly a project to practice good software engineering practices in general.

Point is, in NPM you can do this directly with this command:

npm publish --provenance

Bun does have the ability to publish, but it can't natively generate the provenance statements. You could do something like this, for instance:

bun x npm publish --provenance

But why would you do that? You're literally just falling back on npm to do the work. I thought bun was supposed to replace npm (among other tools.)

Even if you don't care about that though, another feature I need is to be able to generate type declarations (.d.ts files.) I don't see why bun can't do this natively, again you can fall back on tsc but to me that's defeating the purpose of it being an all-in-one toolkit.

Unit Testing

That was a not-so-quick sidebar, huh? Let's get to the story, which will probably be shorter than the sidebar/rant. I used to maintain an npm package called T6 which was an extremely simple testing library, used to check for equality, inequality, string comparison, and boolean comparison. I installed T6 as a devDependency on all my other npm packages, and wrote probably hundreds of one-liner tests throughout my packages. It was fine, but as part of this I'm trying to learn better software engineering practices, I wanted to use NodeJS's standard, built-in testing suite, node:test and node:assert/strict.

This generates a much more easily-debuggable output when running unit tests and it actually forces you to write better code, too. Here's an example of before and after switching from T6 to the standard testing suite.

// Before:
T6.isTrue(SMath.approx(0.1 + 0.2, 0.3));

// After:
describe('approx', () => {
    it('should determine if numbers are approximate', () => {
        assert.ok(SMath.approx(0.1 + 0.2, 0.3));
    });
});

As you can see, the describe/it test contains much more code than T6, and this would be tedious work for hundreds of tests. So, I succumbed to the dark side and turned to AI. To me, this is just busywork anyway, and not actually something fun and complex like building a new feature.

I went file by file, asking Copilot to revise the testing suite to remove the T6 dependency and use node:test/strict and node:assert. 20% of my monthly tokens later, about 700 lines of code were added and 970 lines were removed. (The higher number for "removed" can likely be explained due to the deletion of my T6 source code.) It hallucinated a little bit and changed a few tests, which were easy to catch due to node:test's very nice interface. Here's an example of what it looks like in action.

▶ approx
  ✔ should determine if numbers are approximate (0.706837ms)
  ✔ should treat negative tolerance values as absolute tolerances and reject NaN comparisons (0.20486ms)
✔ approx (2.134829ms)

Conclusion

It was nice being able to remove yet another dependency from my packages. I am still reliant on my build architecture (e.g. tsc, eslint, webpack, and typedoc) but any code that's actually used in my packages is fully mine. The unit tests get removed before publishing, so even those won't ever arrive to anyone's node_modules folder.

Honestly, I'm excited but a little bummed how much AI can do nowadays. I feel like these projects seriously sharpen my programming skills, and if we were back in the late 2010's, I could land a six-figure job writing a few lines of React, easy-peasy. But, on the plus side, AI does help me zip through these projects and move on to the next challenge faster than before.