How I Deal With Unsafe Packages

Obviously I love TypeScript. Sadly, not everyone does, and even fewer get typesafety correct when building packages with TypeScript.
I hope my demo of adding better typesafe wrappers to both PostHog and Inngest is helpful to y'all!
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4se0n3 for the awesome edit 🙏

[@readywhen]

Thanks theo, I'll tell her she doesn't have to worry about my package being unsafe

[@hsthast7183]

As long as it's inside a 'wrapper' 😂

[@arcrad]

Now that's good DX

[@huge_letters]

You don't need a helper - just make a function you return generic on the key :) (event: TKey, data: TRouter[TKey]['input'])=>null Also I think with the way you did stuff you can pass to event of type A data of event of type B. You get errors in your example because none of your events have data of this shape but you can still pass data from other events - even though you shouldn't be able to.

[@justkant]

Nice solution on the returned function I think that he could also keep both `TRouter` and `TKey` in the first generic by adding a default generic type like `TKey extends keyof TRouter = keyof TRouter`, not sure if there is drawbacks to this tho

[@huge_letters]

@@justkant no, the problem he was trying to solve is that if you specify a generic manually - you have to specify all of them, even if these generics have default values and TS can infer them. You still have to type them out - so Theo wanted to expose a createClient function which only has one generic parameter TRouter

[@flyingmadpakke]

This. To add context to this general pattern, as the outer function (helper) doesn't use the TKey parameter at all, it doesn't need to enforce any constraints on it. Coupling the constraint at the latest possible point (In this case the first returned function) decreases coupling overall and makes the code more versatile while maintaining the same level of safety (its that same old loose coupling = more good). So, this is something to look out for with all functions returning functions, are the type constraints defined at the right level, or could they be moved inwards? Similarly, this can sometimes be used to refactor functions into functions that return functions or classes for this exact same reason :D

[@muslim8622]

God ! This thumbnail is S-tier ! Don’t change it, pls

[@ahmedAltariqi]

First example: wow I understand TypeScript 😮 Second example: WTH is that 🤯

[@pau1phi11ips]

Yeah, it's mental

[@AlvarLagerlof]

The Posthog example is great! Much easier than a bunch of functions with typed params.

[@JR-lo2ei]

I haven't had the benefit of code review, being a longtime startup founder. Videos like this make me feel like I'm getting the code-review experience without any of the finger-pointing.

[@ViorelMocanu]

I resonate with your frustration, and I'll steal some of your ideas because I have a task I kept postponing to standardize the way we send Analytics events to multiple 3rd party APIs and a "middleware" like that needs a type-safe interface like this. Great video, thank you!

[@beck4715]

One thing I tried to do (but didn't end up having time for) was doing something similar for our i18n strings. The goal was to use EN as the source of truth and through TS magic, make sure we catch typos in key names and whatnot. Maybe there's something I'm missing here but it seemed neat and very doable with TS

[@FIIRdesu]

Am using something similar on frontend side when calling our own backend procedures. The name of the procedure is the generic key, and the parameter and return types are inferred. But those types are all generated from the database instead of handwritten, so you can reliably get compiler errors when the backend does breaking changes.

[@yiannis_p]

Damn I always know a Theo thumbnail is gonna kick ass but hell this one is just too good 👌

[@soverain]

Good ol' wrapper never disappoint.

[@Guilherme-qk9so]

I thought you meant "unsafe" as in security, not type safety

[@thadtayo]

Okay, I really thought this would be a video about how Zod has a massive vulnerability right now. Good video regardless!

[@ChadElliott_THEtheChad]

What's the massive vulnerability?

[@thadtayo]

Zod V3.22.2 ReDoS@@ChadElliott_THEtheChad

[@ChadElliott_THEtheChad]

Curious why you created a helper function vs extending the module declaration. Obviously it's more difficult but you dont need to add additional runtime code to simply add type safety. Not to say i haven't done this myself 😅

[@oussama40612]

I too expected module augmentation instead of this wrapper function...

[@armaandhanji7151]

Thanks for the great content Theo!

[@EraYaN]

Why not have the event types be methods on a class or functions? Is there some reason that can’t work?

[@jordihc]

My guy. I was literally trying to add this a few weeks ago to inngest, but gave up. Certified boss

[@eshanchatterjee1250]

What do I do if my workplace and coworkers don't use proper types at all. I literally have a ts file that has around 1.5k lines of code that is purely types no logic just type definitions, that's how I get any type hints Edit I just don't understand why people refuse to use types

[@flyingmadpakke]

You need to ease them into the addiction, you can't just give them pure cocaine from the start. You start by suggesting them build-in type mappings/predicates, stuff like Partial, Required, ReadOnly and NonNullable are good starting points. Then you can show them how to create their own type predicates, mappings etc. At this point, you should start seeing their addiction feed itself. Now they are ready for the heavy hitters, filtered mappings, recursive types, type set theory etc. Once they write more meta code than code, and can prove that "any" is actually the paradoxical aggregation of the set of everything and nothing, only used by heathens, then you will know they have reached the final stages of addiction :)

[@henzyd]

The editor looks cute

[@SXsoft99]

Wrapping a specific existing package logic in project specific logic to enforce certain rules. I have to wonder how many newbies look at this and get their mind blown

[@andymutale368]

Ah just what I've been struggling with tgis past week

[@davidsiewert8649]

Where are the links to the source code?

[@skeleton_craftGaming]

I consume external dependencies for breakfast. That's why I write my own code [because All my external dependencies are well in my stomach ; so I can't use them] though you think this is bad in flipping type script... Try correctly using a C api in C++

[@lighty262]

You define unsafe packages by data types? 🤨

[@Cruzylife]

Why the 1am drop

[@yourlow]

I am now type pilled

[@avid459]

I am surprised there isn't a package to deal with unsafe packages😂

[@karsongrady]

if (package === unsafe) { wrapit() } ~theo

[@Its-InderjeetSinghGill]

Nice thumbnail though 😂😂😂

[@joshix833]

Why are calling code with any type safe?

[@samuelgunter]

The only way to stay 100% safe is to abstain from using all packages

[@LGREC15]

LMAO "POST HOG"

[@arashitempesta]

me barely understanding how to use basic generics for reusing components watching this vid 😅

[@abc123evoturbobonker]

I dunno, starting to sound a bit like JDSL..

[@keith-is-mad]

5:25 - people shortening the "generic parameter" to just "generic" always triggers me internally. it's like calling "a function parameter" - "a function".

[@Igstefano]

Username checks out

[@daleryanaldover6545]

I do similar thing but in JSDoc

[@user-dj6or6sz4u]

im so stpd

[@kearfy]

pnpm rm …

[@tanishqmanuja]

Unsafe meant Not nicely typed packages 😂

[@steav677]

typescript's inferring mechanisms are some works and others don't. That's fucking annoying. I understand why a handful ppl hates typescript. typescript is not a perfect type system yet.

[@steav677]

but I LOVE typescript though

[@theLowestPointInMyLife]

That's some of the worst code I've seen in a long, long time. It's just typescript masturbation at that point.

[@siduck_og]

ugh typescript!