I just spent far too long trying to bend Zed to my will. It reminded me of how I needed multiple weeks on and off configuring and reconfiguring VSCode to work for me. It is rare that the defaults provided in a code editor work for me. So I tried, and I’ve given up for a few very important (to me) reasons…

I am thrilled to announce the first major version of oneRepo. Many years of experience creating monorepo tooling for high performance frontend, JavaScript, and TypeScript teams at major organizations has led to the creation of this command-line interface, an API, and a toolchain for better, safer, and faster monorepos.

It cannot be denied just how fast Rust-based linters for JavaScript are. The major tools available now are Biome and Oxc, both running at nearly 100x the speed of ESLint. But they have one major drawback and I don’t think they’re going to take over ESLint without it…

This little hill I will forever defend. The shorthand syntax for Arrays in TypeScript is unnecessary and unclear.

Taking a look back at the things I was hoping to see more of in 2023 for JavaScript and frontend development.

Here’s a little trend for 2023 that’s going around: listing out the default apps (and tools!) that I’ve used in 2023. I enjoy this little go around, as I’ve been getting to discover new apps that I might want to try.

A short recounting of the thing that changed my mind forever on strict type checking for JavaScript.

Path aliasing, sometimes referred to as import or module resolution, in the earliest and most naïve sense, is a method of overloading the Node Require Resolution Algorithm so that it first looks in some particular defined folders for modules of a given name before looking for installed modules of the same name in node_modules folders. While this seems handy at first glance, in practice, it’s is an unnecessary maintenance overhead in large distributed teams and a sign of poor code organization and architecture.

When was the last time you stopped to think about the cost of a new third-party package that you’re adding into your process?

Where do you recommend balancing between “not invented here” syndrome and using packages just because they exist? I always come back to the “left-pad incident” as an extreme example to avoid the latter, but where should we be drawing the line between the two?

Let’s take a moment to break down considerations that I try to make when balancing writing code against pulling in third-party modules…

How do so many people just ignore cruft in their projects and keep moving forward? I was fighting with a bunch of package.json files recently that had 10s of dependencies that were completely unused. Why was it left this way?