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.

[andrewpeters9]

@sanny-io Pardon late reply. Before reading this I realised the same thing while thinking about the MR over the last week.

Some other thoughts:

• if we were to enforce these types then we would also need to do a creation of migrations to ensure that the underlying data is actually prefix_{id}
• by chance, do you think the refining of types would be better placed above the @id layer, as there may be cases where you want to create template-literal types for fields other than id's?

E.g. a rough example

model Model {
   field  String @templateLiteral(["prefix_", string])
}

And then this would be internally handled by either zod validation or whichever way emails were validated when a user would do @email

At the same time, this doesn't exactly provide us a clear pattern, as the addition of @email didn't produce migrations (and rightfully so).

See: https://zod.dev/api?id=template-literals

[sanny-io]

@andrewpeters9 good points you bring up.

A @templateLiteral attribute could be the right direction. There was actually recent talk in the Discord of being able to control some aspects of type generation, which is now being tracked in #627

That feature might be of interest for an implementation of template literals.