I preface by saying I generally love TypeScript, but sometimes I wish that some things were more explicit, or the type system a little less magical.
In the NoInfer example, they imply that
function createStreetLight<C extends string>(colors: C[], defaultColor?: C) {
has an unwanted current behaviour of allowing the type of C to be any string in the second argument. I’d argue the opposite, this is what I would expect to happen. According to the type signature, I would expect any string to be valid for C, whether or not it was included in colors. The addition of NoInfer makes it possible to restrict the inference of C in some arguments while allowing other arguments to be inferred, which is good, but I’d still expect C to be able to be any string. In my book, if someone wanted to limit C, they should have to do it explicitly as a type (e.g type Color = "red" | "green").
The addition of better support for how Bun works for imports is nice too, but it also makes the confusing options for module/module resolution even more confusing. The flexibility is good for tools that build on top of it, but adds a lot more cognitive load if you come across a project with different config options for module/module resolution. That said, I think that Bun is the most promising solution for handling imports in JS, no more scary esm errors. So I welcome it.
I’d say that inferring a generic type to be a specific subset of values implicitly describes a generic, vs explicitly defining a type. So yeah, it’s a problem I have with how the generics work, but it’s because the inference via NoInfer is implicit at the type level, rather than explicit.
In other words:
createStreetLight(["red", "blue"], "green")
Inferring C to be a subset from argument 1 makes it less explicit at the type level, though it’s explicit at the value level. I would push devs to explicitly define the type restrictions over relying on the inference to work implicitly.
I don’t like that they announce VSCode improvements alongside the language release. Were these improvements made to the Language Server for typescript?
Interesting question! These changes are made directly in the Typescript repo, and they’re exposed via tsserver, which is the official editor tooling that TypeScript provides. I’m not super familiar with the other LSPs for TypeScript, but it doesn’t look like they use tsserver
I preface by saying I generally love TypeScript, but sometimes I wish that some things were more explicit, or the type system a little less magical.
In the NoInfer example, they imply that
has an unwanted current behaviour of allowing the type of
Cto be any string in the second argument. I’d argue the opposite, this is what I would expect to happen. According to the type signature, I would expect any string to be valid for C, whether or not it was included in colors. The addition ofNoInfermakes it possible to restrict the inference of C in some arguments while allowing other arguments to be inferred, which is good, but I’d still expectCto be able to be any string. In my book, if someone wanted to limit C, they should have to do it explicitly as a type (e.gtype Color = "red" | "green").The addition of better support for how Bun works for imports is nice too, but it also makes the confusing options for module/module resolution even more confusing. The flexibility is good for tools that build on top of it, but adds a lot more cognitive load if you come across a project with different config options for module/module resolution. That said, I think that Bun is the most promising solution for handling imports in JS, no more scary esm errors. So I welcome it.
That’s not “more explicit,” that’s just saying “I don’t want typescript generics to be able to model that case.”
More explicit would be “I’m okay with this being modeled but with this more explicit syntax instead”
I’d say that inferring a generic type to be a specific subset of values implicitly describes a generic, vs explicitly defining a type. So yeah, it’s a problem I have with how the generics work, but it’s because the inference via
NoInferis implicit at the type level, rather than explicit.In other words:
Inferring C to be a subset from argument 1 makes it less explicit at the type level, though it’s explicit at the value level. I would push devs to explicitly define the type restrictions over relying on the inference to work implicitly.
I don’t like that they announce VSCode improvements alongside the language release. Were these improvements made to the Language Server for typescript?
Interesting question! These changes are made directly in the Typescript repo, and they’re exposed via tsserver, which is the official editor tooling that TypeScript provides. I’m not super familiar with the other LSPs for TypeScript, but it doesn’t look like they use tsserver
All the LSPs are just adapters for tsserver.