Node.js Now Has TypeScript Type Stripping On By Default

2025-11-01T20:45:00Z

Despite keeping up better with my RSS feed reader lately, I still missed that Node.js v22.18.0 enables TypeScript type stripping by default! Apparently it has also been enabled in v24 since its initial release.

This is great news, because it means that with some important caveats, it is now possible to run TypeScript natively in Node without needing to specify the --experimental-strip-types flag. The caveats boil down to the fact that not every TypeScript language feature can be cleanly stripped to create valid JavaScript — a small handful of features require the TypeScript compiler to generate JavaScript code in order to fully function.

Luckily, in TypeScript v5.8 they introduced the --erasableSyntaxOnly option. This raises errors when you use one of these features that would cause Node.js to throw a JS parse error even after type stripping.

The full list of these non-erasable language features is thankfully small, and, in my usage of TypeScript, quite manageable:

namespaces and modules with runtime code
import = aliases
Parameter properties in class constructors (the shorthand where class { constructor(readonly foo: Bar) {} } auto-creates a foo prop)
enum declarations

I don’t think I’ve ever used executable code in a namespace or a module — the only time I use those is if I need to extend global or package types. I don’t think I’ve ever used import = aliases. And I can easily live without parameter properties.

Lack of enums is probably the toughest pill to swallow. But the TypeScript docs for enums have a good suggestion — instead of creating an enum create an object with as const:

export const Direction = {
  Up: 1,
  Right: 2,
  Down: 3,
  Left: 4,
} as const

export type DirectionEnum = (typeof Direction)[keyof typeof Direction]

Hopefully this proposal for an as enum assertion gets some traction, since it would be nice to not need an extra [Name]Enum type.

There are two other TS options that are helpful for running type-stripped TS in Node: rewriteRelativeImportExtensions and verbatimModuleSyntax. The former helps ensure you can use .ts extensions in your import statements, and the latter avoids surprises from top-level side-effects when importing a TS module.

Private Branches in Public Repos

2025-10-11T21:47:00Z

Something that’s semi-frequently bugged me about having this site be statically generated from flat files in a public GitHub repository is how to deal with drafts of posts. I want to be able to save my progress “in the cloud” so that I can pick it up on other machines without making anything half-baked publicly accessible.

The way I have been dealing with this is to use a persistent GitHub Codespace where changes can just sit untracked. But this means waiting for the Codespace to initialize when I start working on something, dealing with it pausing after inactivity, or even paying a bit for it if I go over GitHub’s free allotment. Without increasing the number of vCPUs on the Codespace, it’s also significantly slower than any machine I would use.

So a few times I’ve gone looking for a better solution to this problem and I’ve come up empty. But last night I decided to try again, and I gave this prompt to Claude:

I wish I could have encrypted WIP branches in public GitHub repos. Does such a thing exist?

The response told me a bit about encryption options, but the first two alternatives it gave hints at something better:

Private branches - Just use a private repo for WIP, then move to public when ready

Fork workflow - Keep your fork private while the upstream is public

This made something click for me. If I created a private fork that only exists to store branches of work-in-progress, then I could add it as a remote to clones of the public repo. This would effectively let me have “private branches”! Finally!

I’ve implemented this by creating an empty private GitHub repo, added it as a remote named private, pushed up everything from the original, and renamed the origin remote to public. This rename makes sure I will need to explicitly specify a remote when pushing new branches, preventing accidental pushes to the public repo.

git remote add private https://github.com/limulus/limulus-dot-net-private.git
git push private --all
git remote rename origin public
git checkout -b my-wip
git push -u private my-wip

When it comes time to merge my work into the public main branch, I can do this easily with plain old git merge. If there’s intermediate commits in the branch that I don’t want to be public I can always rebase or squash.

GitHub unfortunately does not track this separate private repo as a fork. That (plus the public/private dichotomy) means I can’t directly make PRs from the private repo. If I were using a PR based workflow, I expect that would have to reset the upstream of the branch to public and then make a PR. But that’s not something I’m planning on doing with this project.

This is one of those things where I feel a little silly for not realizing this was possible. It’s obvious in retrospect that the ability to have multiple remotes in a repository would allow for this. But it’s a git feature I’ve used at most once before.

Eric's TILs

Node.js Now Has TypeScript Type Stripping On By Default

Private Branches in Public Repos