🦋 Changeset detected

Latest commit: 609671a

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

I wonder if we can be smarter with this. Using something like this: https://xebia.com/blog/typescript-5-0-and-the-new-const-modifier-on-type-parameters/

@TGlide that would definitely be preferable! I actually tried adding the const modifier before using as const but haven't had much luck with it so far. Will try to look further into it because that would definitely be the way to go

I tried using the const modifier and was almost able to do it but it seems like TS has a weird bug that breaks its behavior when used in more complex situations.

The objective is for the props returned from builders to be interpreted as const by using the const modifier with generics to avoid adding as const to every single builder.

I created a mini version of the makeElement function and added a new const generic for the props returned from the builder and here are the results. I enabled TypeScript InlayHints to show the types of variables.

Without declaring the store values parameter, the object is interpreted as const. ✅

If we declare the store values parameter (most commonly used pattern), the object is no longer interpreted as const. 🚫

If we add an explicit type for the store values parameter, the object is interpreted as const. Note that TS already knew the type of the parameter without needing to explicitly define it. But for some reason adding the explicit type, makes the object be interpreted as const. 🚫

@TGlide Unless I am missing something with the const modifier, it seems like it's a little broken and so maybe we should just use as const for now, as it is actually already used in many builders, and then if someone can figure out a better way to do this, they can create a PR