TypeScript 5.5 is a BANGER
ฝัง
- เผยแพร่เมื่อ 29 มิ.ย. 2024
- 0:00 Intro
0:12 Regex Checking
1:08 ${configDir}
2:23 isolatedDeclarations
4:35 My book!
5:33 Type Predicate Inference
8:17 Final Stuff
Sign up to learn more about my upcoming book:
www.totaltypescript.com/newsl...
Follow Matt on Twitter
/ mattpocockuk
Join the Discord:
mattpocock.com/discord - วิทยาศาสตร์และเทคโนโลยี
![ความรักของยักษ์เขียว (ทศกัณฐ์) - เดี่ยว ไออุ่น [OFFICIAL MUSICVIDEO 4K]](http://i.ytimg.com/vi/yCCy-QVHqK8/mqdefault.jpg)
type predicate inference is just delightful.
I love that you chose the word 'delightful'. That's exactly how I feel as well!
Love the type predicate improvements. I've always considered those as unavoidable type casts.
Me too - so useful.
Matt in a nuttshell -> ”yeah so ive been working on this really in-depth-typescript-book for a year now…it will be really helpfull..oh, btw its free”. Awesome, thanks so much for all that you do, Matt 👏
Congrats on the kid and the book. Glad to see so many ergonomic benefits added and the team not letting perfection be the enemy of good.
I Love that you are releasing the Book! ...Will definitely reach for it. You make awesome content. Thank you so much for your hard work!
super excited about predicates! your videos are fantastic and I always get excited when I see a new one drop!
100k pocock!!!! congrats!!!
Congrats on 100k!
Thanks Matt for your video, I'm actually happy when I see your videos in the feed as I know it's not click bait low effort stuff.
7:38 Because 0 evaluates to false in that expression and so the predicate `x is number` would evaluate to false even though 0 is in fact a number
What Matt wants is for typescript to be able to model one-way refinements. So instead of a type that says: "true guarantees x is a number, false guarantees x is not a number", what he and other people actually would want is a type that says "true guarantees x is a number, false guaranteed nothing"
I think it would be reasonable to at least say that x is not null though.
@@osdiab how? What would the type predicate look like in that scenario?
OK, but the rest are still numbers.
@@crabvk A type predicate is in the form of `function (x: unknown): x is T`. In this case `T` would be `number`.
So, if `(x) => !!x` or `Boolean` was to be used as a type predicate and that type predicate would be `function (x: unknown): x is number`, then what you are basically saying is that if `x` equals `0` then `x is number` is false, i.e. 0 is not a number, which is obviously untrue.
So, it doesn't really matter if all others are still numbers, the type predicate would induce wrong behavior, which goes against the entire point of type inferring the type predicate.
Why !!member doesn't result in the desired predicate is actually explained in the release notes. Basically, the number 0 would also return false, so this predicate would be more like `member !== null && member !== 0`. The release notes say that it will work for objects tough, so !!x will correctly remove undefined / null from a union with objects.
Thanks for the book. And yes, type-guard inference solves a lot of problems for me too.
So bizarre that `Array.prototype.filter(Boolean)` still doesn’t infer array to only include truthy values. No idea why they haven’t implemented this yet given how easy it is to implement in user land
Passing built-ins is a pretty bad idea in the first place, just use `(value) => value` callback like all simple-minded folks do.
While I agree, I think it's a minor point. Now you can swap out `Boolean` with `it => it != null` for null+undefined checks instead of rewriting the entrie flow into loops. And you could also argue that that's more explicit. Boolean(0) === false after all.
What would be the resulting inferred type (and type predicate) if the original's array type was (number | undefined)[]?
There's no inference at play when doing .filter(Boolean). Boolean() is a function that happens to work like a type predicate, but it is not declared as such in the js built-in type definitions.
Would've been nice if they did change it, but it's not such a straightforward change because of falsy numbers and strings. I can understand that it was at least out of scope.
@@jeralmsure, but if it's Objects or Null, then there is no concern about falsy strings and numbers
Congratulations on your book; I'm really looking forward to using the regular expression validation feature
As usual Matt, Fantastic job! ❤🚀
Congrats on the 100k subs!
Thanks for yhe video! I really enjoy your content and was kinda sad that you stopped with the shorts format, i loved that and thats actually how i found you. Cant wait for the book and course! Count me in!!!
The same here.
Great release 👌
Indexed access type narrowing is also cool
Type predicate inference is just wonderful, it will save us a lot of problems. Thxs for your great video again! ;)
The website for your book looks so beautiful. Definitely gonna steal some of that.
Can't state how much I've needed type predicate inference. Looking forward to this!
Congrats on your baby fam!
Glad to see you back here Matt, great video! Any plans for a live stream any time soon? Looking forward to read your book as well 🎉
Congratulations on your newborn baby!
Still no .filter(Boolean) 😭
sed -i 's/\.filter\(Boolean\)/.filter(it => it != null)/'
Or something. And some thorough testing. 😀
There is pretty popular eslint rule that enforces Boolean instead of x=>x TypeScript team made a huge mistake not supporting popular variant (again). So it won’t be supported and typescript will be pain to use forever ;(
Checking your RegExs is uh-may-zing! I want that NOW!
OOOH! And Type Predicate Inference is the feature I've been desperate for for ages... Now if the TypeScript team could just put that in to some of the other languages I use, that'd be just lovely. ;)
Chrck for truthiness doesnt work because 0 is false, but zero is still a number, so its correct that it doesn't work
if u do
let val: number | undefined;
if(!!val){
console.log(val) // number
} else {
console.log(val) // number | undefined
}
it narrows the type down to number, so its not a limitation/consistent behaviour.
@@K127able it's not consistent, but, that's exactly the limitation described in the pull request, among others
That book will be the next TS documentation 👀👍🏼 thank you
Big 👍 for the free courses, not many people do that.
waiting for the book
To be honest, I've been using 5.5-rc for like a week or two now.
The best features in this context are ones you don't notice, because they get out of your way.
What did I just notice that I stopped noticing? - I don't do as much type casting. Which is delightful, because casting has a potential (however small) to mess up some of your things and waste quite a bit of your time to notice when you move on to other things.
omg i would love named groups actually working properly in TS. I'm so tired of forcefeeding it the type when it's in theory possible to refer the group names from a pattern. Probably ended up being rather complicated to implement on their end, but I will love it every time I make use of this feature!
For super wizard level typescript, it would be cool if you could go over how some libraries implemnt super complex type inference like Drizzle, trpc, zod and explore TS concepts through their implementation.
That's what I do in TT!
Are you going to make a GPT bot out of your book so people can easily query it for information and examples?
you are TS god! with love from Ukraine
number has no specific trutyness but null doe this is interesting to see maybe it is one level tot complicated for having it now 😅 7:35
Oh yea, last one so annoying, I had to leave a smelled code to type result "as " and it's look ugly and it was not really check if it true or not (like if there is bug in the code), so it was not ideal.
So they implemented 50% of total-typescript/ts-reset. I wonder how long it's going to take for a compiler option to default to "unknown".
I’m not sure this is why it behaves this way, but the !!member and Boolean type predicate behavior of NOT refining the result intuitively makes sense to me, as it actually refines to a subset of the number type excluding falsey values (zero).
Maybe one way to think about it is, if you ran this on boolean[], should it return true[]? What if you ran ran this on (true|false)[]?
At the very least this seems like an antipattern to avoid at least for string or number since you may not want to filter out “” or 0, and thus may not be something the TS team wants to prioritize without seeing how the ecosystem reacts first.
I tested this a bit and got curious with the predicate inference and found something curious:
For example, given the input [{}, null] or [{ foo: 1 }, null] and using the `!!member` expression, it results in types ({} | null)[] for the first case and ({ foo: number })[] for the second. The second is what we'd expect for the first as well.
Not entirely sure why, since `{}` is not nullish or falsy in any way. In fact according to TypeScript itself, the _type_ of {} should represent any value except `null` and `undefined`.
Even more fun is trying with [undefined, null], which will result in (undefined | null)[], rather than expected never[].
I also tried with Boolean for everything, and it doesn't narrow the type at all. This is likely due to TypeScript not treating it specially (since it could be patched) and it not being an expression, but rather a constructor (TypeScript sees it as a BooleanConstructor whose constructor function returns a Boolean interface, not a type guard).
there is a d.ts file generation issue that's been open in tsup for months that this might fix
Is TotalTypeScript Essentials going to replace Beginner's TypeScript Tutorial? Or do you still recommend people with zero TypeScript experience to start with Beginner's TypeScript?
Back references are good for things like `.+?` so you are looking for a closing tag that matches the opening tag.
if you're sure that there are no the same tags inside, that's okay
@@gooseobregex is not a tokenizer, it can only do so much.
If you have nesting you are prob better off with a dedicated html parser. I was just showing a single example
Yeah and it's a pretty bad example.
In general all the fancy regexp stuff dies the moment it has to deal with environment boundaries, like server and client having varying support for fancy regexp syntax. It even can be just server-side problem where two microservices support fancy regexp unevenly due to different underlying languages.
The worst offender is ofc html with `pattern` property of `` elements, which doesn't even allow to pass custom flags and instead opts for some default implementation-dependant ones. Hope you will enjoy the meaning of the regexp changing in subtle ways between browsers and their versions.
So many great advancements to try to rectify something so bad.
As usual, the only PROPER answer is to invent time travel and go to Brendan Eich back then and force him to put types in the flippin' language in the first place.
Not even 0:23 in the video but I just saw a bombshell dropping!!
Regex type safety???!!!!?!?!?!?! aaaaaaaaaaaaaa!
next:
let count = 1 // get type: 1
count++
count // get type 2
This works in a more useful way already:
let a;
a = 'abc'; // string
a = 123; // number
Is there any way of having a checked `value is number`?
Although TypeScript can now infer this, I'd still like to state it explicitly because I see explicit type information as a form of self-documenting code. It'd be great if TypeScript could report "You've asserted this value is a number - but you're checking it's a string!"
Sadly not! Type predicates are by default about as safe as 'as'.
I got happy for a sec until i saw that .filter(Boolean) still doesn't infer types properly
Maybe I'm wrong, but doesn't adding more inference like type predicate's go directly against what the isolated declarations need, which is less use of inferences? That seems very strange to me.
Yes, this is why isolated declarations is enabled under a flag. No reason why the rest of TS shouldn't benefit from inference.
Typescript 5.5 broke global type definitions in our project and we dk how to update 😢
seems like using regexes doesn't narrow types down either, e.g.
const isAlphaNumeric = (input: string | undefined) =>
input !== undefined && /^[a-z0-9]+$/i.test(input)
won't return `input is string` but just `boolean`
Yep, that isn't in scope
still not working with `.filter(Boolean)` => useless release
The reason why !!value and Boolean don't work in this case is because !!null === !!0 and Boolean(null) === Boolean(0) so it doesn't filter non-null values but falsy values.
Sure, but !! works in if statements, so...
@@mattpocockuk yeah right. When I think more about it, it doesn't make sense for the !! or Boolean to not work in those cases... My bad :)
@@mattpocockuk also I was doing some research and look at this:
// Does NOT work
const y = ([0,1,2,3,null] ).filter((x) => !!x); // (number | null)[]
// Works
const x = ([0,1,2,3,null] as const).filter((x) => !!x); // (1 | 2 | 3)[]
it can properly infer type when using const. I think they can improve it in the future versions. I don't think there is a reason why it shouldn't work.
I mean having tons of stuff in root_dir/dist seems a lot more preferable and sensible honestly. It seems a lot worse to have to chase down all the different build artifacts across node_modules every time you want to build from a clean slate. You kinda want your libs to be static and without artifacts. It's already a nightmare to debug dependency issues as it is.
Outputs should be colocated with their inputs, no? Your setup sounds full of implicit dependencies.
@@mattpocockuk An example would be an orm-plugin for a node-backend. It makes sense to create the sqlite dev file as an artifact in root. Same for plugins generating json API specs consumed by docs endpoint generators like swagger. There are probably a lot more examples.
As far as I know there is no way for libraries to generate a npm command in root package.json which invokes cleanup for its own (or all) package.json files in node_modules. This means that state in the tree is hidden making bugs really hard to track down until all problems are mysteriously solved when dev reinstalls node_modules.
If npm has, or implements in the future, a standardized optional cleanup command that also invokes all package cleanup commands in node_modules, this problem might be solved given that library developers implement this new convention.
i hope this doesnt mean more regex... ive seen websites that run 2m regexs on every page load eat up 5s+ of cpu bc someone at adobe decided to use all regexes to built a product
Am I the only who reads Regex as /rejeks/?
Dart had this type of inference 3 years ago. TŚ is lagging so much...
The more users a language has, the slower it evolves.
I think your audio does not sync with the video
100k Good JOB
Hearing you say configDir as confirDeer instead of configDur hurt 😔😔
Lol. The reason why `!!maybeNumber` doesn't work is that 0 is falsy 😅
Lots of people are replying this, but that still means the type would be inferred correctly. It's just a subset of number instead of number. In an 'if' statement, this works. Why not trigger type predicate inference there?
@@mattpocockuk yeah, also figured that after responding. I think maybe because Boolean is also a constructor? There might not be a way to type that yet (a constructor with a type guard as a side effect). Not sure about !!
!! and Boolean wont work cause 0
As a Rust dev I'm still unimpressed...
The lack of truthy/falsy-ness in the type predicate inference knocks down my excitement quite a bit.
7:30 does not work because !!0 is false and !!1 is true
I mean, it'll still filter to a subset of number - and this works in an 'if' statement. So I am a bit surprised that it doesn't work.
I hate typescript bureaucracy. I make copilot deal with it so my repos don't look amateurish. I hope one day we never need it.