Ideas for your TypeScript book: - Teach the TSConfig well with sensible defaults - Mention the annoying caveats with React, etc and how to deal with them. - Idea for a more advanced exercise, maybe for near the end of the book: "Try to implement a Repeat that outputs TString repeated TNum times."

The one thing I am realy excited about is fetch XD But one thing I would love typescript to add is strongly typed throw errors

Think my fav with all this is the throw expression

I'm really glad to discover you. Thanks to you Matt I'm improving a lot 👍👍👍

Thanks for this summary. Looking forward to work with 5.3

Really excited about the narrowing

Great work 🎉

For anyone running into the @typescript-eslint/ban-types: Don't use `{}` as a type. `{}` actually means "any non-nullish value" problem. You can get around this error by doing this instead. type IconSize = "small" | "medium" | "large" | (string & NonNullable); This strips undefined and null from unknown which leaves you with {}, This is equivalent to the code in the video but you no longer have to disable the rule in your editor. Hope that helps :)

great informative video, looking forward to your TS book :)

this was worth the watch just to see some of those hacks!

I would like to have "throws" declarations in typescript. This way we could better describe functions that should have a try / catch block around their call.

Interesting to hear about that string union trick. Might be IDE specific, since I’ve just done `| string` before and WebStorm autocompletes just fine

Hi Matt, can you also check prisma on how we can create props base on the prisma setup, that would be great too 😊

Even cooler than throw expression would be return expression. The throw case can already kind of achieved by wrapping it in a function, but with return that is not possible.

I hope they allow import statements with extentions

can't stop the TS-train 🔥🔥🗣🗣🗣🗣

throw expression and (string & {}) 👌👌👌👌👌

they substituted the previously deprecated with keyword for import-type-assertions???

autocomplete for "| string" lets go!!

Well, the autocomplete is indeed a cool feature. Linter has always been pissed about an intersection type with a {} 💩

Let em ship

I’d rather have nullish coalescing throw. It is way obvious in null pointer context: (example): null ?? throw new Error(‘…’);

Don't really get import attributes. If the argument is security, then you could have a compiler flag that checks if the extension that you are trying to import is actually what it claims to be. If the counter argument to this is that you want to do it selectively, then something like: import json from './foo.json' with check; would be more clear. But I guess this gives freedom to import any extension and check for any extension at the cost of boilerplate.

I don't understand the IconSize example. If you want other values, then why not include them in the union?

Finally they fixed throwing errors in conditional statements...

Oh they are fixing the string autocomplete thing? I have a lint rule that disallows using {}, so I guess the eslint disable comment there is now officially temporary :)

#NotSoHotTake: Errors as value > Throwing. The fact that you can't know if a function is going to throw or not and the inconsistency in the "standard" library are incredibly frustrating! Return an error type like Go and Rust, have strong prototypes like the Option or Result in Rust, either way would be 100 times better than throwing errors.

Nice but can browsers finally start allowing import json?

Not personally a fan of the proposal for imports. If you give developers the option, most won't use it and the rest will probably use it wrong. Since there's no reason I know of to ever import, for example, JSON with type Javascript, only ever with type JSON, just infer the "with" type based on the file extension and do the security check behind the scenes. And with that, you just automatically boosted the security of every Typescript application from 5.3 onwards without any developer needing to do anything different. _That_ would be a good change.

Has anybody tried Matt's courses ? On Reddit people disliked his courses a lot since it's pricey and don't teach much, all he did was just giving problems that will never be appeared in real life or anything like that ? I am confused here. His content on youtube is too good to even believe that.

Well, the updates start shippin' and they don't stop shippin'…

Throw expressions are very weird, an expression whose value is never used and one that only exists for its side effects? weird imo.

string & {} 🤯

Needing to include the dom lib types just to use native fetch has always been really annoying

They need to simplify TS, not make it more complicated... unless it increases DX and developer ergonomics.

I think Next version should be: Integrating TypeScript with Copilot marks a new era where AI handles type management, freeing developers for more innovative tasks. Let's redefine our workflow, making types the domain of AI, and elevate creativity for developers! it's 2023!

Typescript moving too far ahead from Javascript the main function is types. But they now act like it's their language and trying to force Javascript features to be added.

exceptions as an expression ? i hope this never happens. you either deal with exceptions, which is a side effect, or with errors as value, but why mix both ? i think this is really stupid and yet another pile of junk on top of javascript.

“Type”Script taking types too seriously

Throw Expressions would be amazing...you can have them today with..... const X = Y || (() => { throw Error('nope') })()