Sasha πŸπŸ’¨ Koss

Sasha πŸπŸ’¨ Koss

@koss.nocorp.me

I make rad things. Many are open-sourced, like date-fns. Some, like https://mindcontrol.studio are not.

523 followers312 following197 posts

🚨 New open source by me and my partner Josh: Mind Rig, AI playground for VS Code, Cursor, and co. πŸ”Ή Test prompts against different models & settings. πŸ”Ή Inspect requests, responses, and usage. πŸ”Ή Assign prompt variables manually or use CSV to test against multiple values.

Hear me out. TS has namespaces, but they aren't open and defined per module, unlike Rust impl or C#/C++/etc. Even if JS had it, it would be a nightmare for bundlers. What if we used a delimiter, i.e., $: Result$initFromRun() or <Result$HorizontalLayout /> to signify them?!

This will enable typing Result$ and getting suggestions for the namespaces from whole database. I practice hierarchy-based naming (e.g., ResultLayoutHorizontal), which is practically the same but implicit, gets mixed with unrelated names, and sounds unnatural.

Two monorepo learnings for the past couple of years: 1. TypeScript Project References rule in terms of performance and DX. 2. Extracting app code into isolated packages is not worth the hassle. When sharing code between apps, it's better to just have a single "core" package.

View full thread

2. I committed to extracting app code into "aspect" packages, and it has its benefits, but dependency wiring is just way too tiring. Moving and sharing code gets harder with every new package. Now I have monolithic "core" package that I share between apps.

2... I create a new package only if - It's a separate service (production or dev app). - It's a package shared between monorepos (currently I use Git submodules to do so), so fewer external dependencies. - It's an open-source library published to a registry (which is rare).

Two monorepo learnings for the past couple of years: 1. TypeScript Project References rule in terms of performance and DX. 2. Extracting app code into isolated packages is not worth the hassle. When sharing code between apps, it's better to just have a single "core" package.

1. I tried to work with recommended Turborepo setup with `tsc` for each package for few months and got back to references. I got tired of routinely restarting VS Code just to resolve weird problems. Also, single `tsc --build --watch` is just the best way to work on a TS project.

I added two more functions, `todo` and `ensure` (that assert non-nullish, unlike `always` that asserts truthiness). Also, I covered it with tests and detailed JSDocs. Who would've thought that one could push such a simple code that far!

I just published the stupidest npm package, `alwaysly`. There's nothing to it but two one-liner functions. I use them often and am too lazy to drag them around. Btw, if you don't use this pattern in your TypeScript code, you're missing out!

I ended up wasting so much time rewriting stuff that seemingly worked but was actually subtly buggy on many levels. This is why I dislike using "spec" to describe agent instructions. It leads to an illusion of control, while you are, in fact, slowly rolling to a cliff edge.

If left unchecked, agents eventually end up hook-locking themselves and unable to progress. I got this effects spaghetti after just a few (spec-driven!) sessions. It is simply deciding whether to show a key form, form with an error, or a masked key view.

On the other hand, I'm having so much fun designing solid architecture and also writing a lot of code! I'm actually happy that LLMs are bad at making changes keeping big picture in mind. They leave all the joy to us!

Oh yeah, there's no such thing as too many GitHub stars: github.com/kossnocorp/a...

github.comGitHub - kossnocorp/alwaysly: Runtime-agnostic assert function to mark unreachable code pathsRuntime-agnostic assert function to mark unreachable code paths - kossnocorp/alwaysly

I just published the stupidest npm package, `alwaysly`. There's nothing to it but two one-liner functions. I use them often and am too lazy to drag them around. Btw, if you don't use this pattern in your TypeScript code, you're missing out!

I just published the stupidest npm package, `alwaysly`. There's nothing to it but two one-liner functions. I use them often and am too lazy to drag them around. Btw, if you don't use this pattern in your TypeScript code, you're missing out!

Over the years only three organizations realized their promise to support open source, despite endless stream of startups and coins contacting me. They are Open Collective, @github.com, and thanks.dev (they are so awesome, I don't understand why not so many people talk about them) ❀️

The only podcast I'm listening to nowadays is @syntax.fm. So fun and educational too! Always learn something new. And that's not because they, along with @sentry.io, sponsor date-fns via thanks.dev, but for that, they are absolute legends!

It is a massive achievement for such a big company to put money where their mouths are. I wish more companies were that dedicated, not for my wallet's sake, as I spend more money on Sentry than they gave back πŸ’Έ, but for the health of the community!

I love using Next.js for web apps, but man, having to use Vite with React Router for a VS Code extension webview is liberating! A simple SPA with no care for latency is closest one can get to React-promised joy.

If left unchecked, agents eventually end up hook-locking themselves and unable to progress. I got this effects spaghetti after just a few (spec-driven!) sessions. It is simply deciding whether to show a key form, form with an error, or a masked key view.

View full thread

My takeaway is that you can't vibecode something like that. It needs an engineer in the loop, constantly improving the system. This is despite detailed specs. In hindsight I should've designed it myself, but it's hard to notice the problem without writing the code.

If left unchecked, agents eventually end up hook-locking themselves and unable to progress. I got this effects spaghetti after just a few (spec-driven!) sessions. It is simply deciding whether to show a key form, form with an error, or a masked key view.

Nothing to refactor at this point, just a full rewrite. The complication comes from the fact that VS Code extension backend communicates with a webview via messages, and without architecture established by a human engineer, it is doomed to fail.

As MCP maintainers, I think it is important to show the will to choose the right decisions over the ones that benefit the business. It is a small issue, but therefore, it is very telling. If they ignore it, then we will know that the same will happen with MCP eventually.

I think @anthropic.com is now at a crossroads with this seemingly insignificant decision of whether they should adopt AGENTS.md: github.com/anthropics/c... Do they bend to their competition or keep the advantage? This might hint to us if MCP is in good hands.

I tried different code agents, including GitHub's Copilot (all the models), Cursor, and Windsurf. I found them all too slow. Code quality is not up to my standards. Fine for simple tasks, though. Now, after working with Claude Code, I'm finally having a good time.

Now I have a smol family of libraries focused on build size and performance: πŸ”· tinyfloat Β· github.com/kossnocorp/t... πŸ”· smolxxh Β· github.com/kossnocorp/s... πŸ”· smolcanon Β· github.com/kossnocorp/s... πŸ”· smolcsv Β· github.com/kossnocorp/s... (🚧 WIP)

github.comGitHub - kossnocorp/tinyfloat: A tiny (0.5 kB) decimal type for JavaScriptA tiny (0.5 kB) decimal type for JavaScript. Contribute to kossnocorp/tinyfloat development by creating an account on GitHub.

I just published smolcanon@0.2.0 that serializes JS values into a stable string representation. Happy to say it's 30% faster than alternatives, and it's just 185B! I built it to use with my other library, smolxxh (just 381B), to get JS value hashes.

I just published smolcanon@0.2.0 that serializes JS values into a stable string representation. Happy to say it's 30% faster than alternatives, and it's just 185B! I built it to use with my other library, smolxxh (just 381B), to get JS value hashes.

It is especially powerful in a private repo when you want to have some workspace packages open-sourced but keep developing and testing them as a whole.

People are sleeping on git submodules. I used them for private projects for years and recently adopted them for date-fns. With pnpm workspace, I can work on multiple packages in a single project while having GitHub issues and actions separated.

People are sleeping on git submodules. I used them for private projects for years and recently adopted them for date-fns. With pnpm workspace, I can work on multiple packages in a single project while having GitHub issues and actions separated.

How deno_doc is that good? --json outputs data structure I always needed to render date-fns docs. I wish I had discovered it earlier. I dread migrating the documentation website once again, but I feel it would be worth it!

ADRs (Architecture Decision Records) are immensely beneficial but also tedious to write when following the recommended templates. So I found myself avoiding writing them. Now start with just bullet points to capture the essence. Perfect is the enemy of good.

I'm working on dissecting TypeScript type system to breakdown all the magic that powers the most complex generics. Here's the assign compatibility matrix of all basic types.

Did you know about the everything type in TypeScript? type Everything = {} | null | undefined; It behaves not like you would expect, and you can assign anything to it, even unknown, that can only be assigned to any and itself.