The TypeScript keyword I see misused most is as. Most of the time you wanted satisfies, which checks the shape and keeps the narrow type.
What as actually does
Every as SomeType is you telling the compiler to stop checking. Sometimes you need that. Usually you do not.
type Config = { port: number; host: string };
// Compiles fine, even though host is missing
const a = { port: 3000 } as Config;
// Error: property 'host' is missing
const b = { port: 3000 } satisfies Config;What satisfies gives you
satisfies validates the value against the type and leaves the inferred type alone. You get the check and you keep the precise literal types, instead of widening everything to the annotation.
const routes = {
home: "/",
blog: "/blog",
} satisfies Record<string, string>;
routes.home; // still known to exist, typed as stringThe rule I give my team
If you write as, write a comment explaining why the compiler is wrong. If you cannot write that comment, the compiler is not wrong.
The codebase got noticeably safer after we started enforcing that one habit in review.
Takeaways
asturns off type checking for that expression.satisfieschecks the shape and keeps the narrow inferred type.- Every
asshould come with a comment explaining why the compiler is wrong. - Enforcing this in review is a cheap, effective safety habit.
Building something like this?
I'm Ahmed Mamdouh, a senior full-stack & AI engineer. I reply within one working day.
Scaling 100k WebSocket connections: the reconnect storm
At 100k+ concurrent sockets, the hard part is not the count but the reconnect storm; jittered backoff, load shedding and resumable sessions fix it.
npm v12 blocks install scripts by default
npm v12 no longer runs preinstall, install or postinstall scripts unless you approve them, closing a common supply chain attack path.
Node.js moves to one major release a year
From Node 27, Node.js ships one major a year and every release becomes LTS, ending the odd/even split most teams already ignored.