feat: add template literal types for formatted ids

[andrewpeters9]

Marking this as a draft, as it still requires more work & I was wanting input from the maintainers.

Idea:
Allow for the TS types of the newly (optionally) formatted IDs to narrow to prefix_{string} as opposed to just string:

type User = {
   // new behaviour
   id: `user_{string}`;
   // old behaviour
   id: string;
}

Motivations:

• It provides a great level of granularity to type-safety, e.g.:

const fetchUser = (userId: User["id"]) => {
   // would ensure that no random strings can enter the function
}

Concerns:

• will be a breaking change to people's types (but not their runtime), as some (like myself) may have already been using User["id"] with the assumption that it casts to a string
  • IMO, it would be a sane default, as most people that are prefixing their IDs are generally working in repos where type-safety is crucial
  • but if you disagree, we could potentially add a flag e.g. narrowType or something (defaults to false)
• TS performance of these ternaries

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[andrewpeters9]

This file is a bit verbose - let me know if you'd prefer me to trim it down

[andrewpeters9]

Couldn't find a more appropriate file for this (but admittedly, seems very misplaced 😅)

Advise if you have another file in mind / or would prefer a new file

[sanny-io]

This would be a very cool feature. I hope everything works out in the end, because I do agree that this is a big improvement for safety. And I'm happy to see more improvements for ID formatting so quickly after its release :D

[andrewpeters9]

This would be a very cool feature. I hope everything works out in the end, because I do agree that this is a big improvement for safety. And I'm happy to see more improvements for ID formatting so quickly after its release :D

Thanks for the feedback :)

Given you implemented this feature: do you think it should default to the narrower type of prefix_{string} or should it require an opt-in flag?

@sanny-io

[sanny-io]

@andrewpeters9 we are in a bit of a pickle at the moment because the format is not actually enforced at runtime. There's nothing stopping the user from inputting whatever ID they wanted, so the most appropriate type for the ID is indeed string, but I am of the opinion that users should not be able to do that, which is why I proposed #524.

If an ID field is readonly and has some inferable default value, then I think it should be narrowed. That makes the most sense to me because it maps 1-1 with const vs let in TypeScript. Whether that's feasible given the current constraints, I don't know.