Removal of undocumented support for type alias with Prisma 4.0.0

[pimeys]

With the release of Prisma 3.7.0 the VSCode extension (and other IDEs using our language server implementation) will start to show a warning when we detecting unsupported usage of the type keyword.

An example of that is string aliases such as:

type MyId = String @id @default(dbgenerated(new_uuid()))
model A {
  id MyId
}

We plan to remove that functionality entirely with the next major release of Prisma. If you happen to depend on similar functionality for string aliasing, please leave a comment.

Thank you!

[pimeys]

We will trigger a warning for our users who happen to use them in their code, so we can ask some questions and maybe decide on actually doing a real implementation with docs and such.

[Jolg42]

This is an example of a warning from the VS Code extension that will be shipped in 3.7.0

[jycouet]

Any plans to have an other way to do:

type MyId = String @id @default(dbgenerated(new_uuid()))

Something like?

alias MyId = String @id @default(dbgenerated(new_uuid()))

[janpio]

We have a related issue @jycouet: #5039 Does that fully match what you are asking for? If not, feel free to open a new feature request issue - that sounds like a reasonable suggestion. (Are you currently using the old type?)

[jycouet]

Yes, #5039 is maching what I have in mind. thx.
I'm not using old type. I saw it today that it's deprecated now. It seemed to be a so nice thing to do.

[JonathanWilbur]

I'm not totally opposed to removing it if there's a suitable alternative, but, why are we removing this? This seems like a perfectly useful feature. Is it doing any harm by being there?

Here is an example of where I use it:

// Period-delimited numeric-only object identifiers.
type OIDs = String

It might seem trivial, but being able to alias types like this makes my schema more self-documenting. I'd like to continue using this, or something that can at least currently provide this functionality.

[pimeys]

A few reasons:

• It was never documented
• We inherited it from Prisma 1
• It is almost completely not tested anywhere
• And it is quite broken with certain use-cases
• It is not very thoroughly designed, there are weird edge cases

What we should do is to design something proper, test it and discuss it. Then finally document it. I think a new keyword alias would be a good idea, if people think they have uses for it.

[JonathanWilbur]

Okay, thank you for clearing that up. I do think alias would be a more technically-correct word for this.

[maxh]

For what it's worth, my team had been planning use type aliases to work around date and datetime limitations in Prisma: #4355 (comment)

Looks like we might need to rely on our own comments or parsing on top of the Prisma schema to get the desired behavior.

[janpio]

Yeah, sorry about that - but those were only partially implemented anyway so I would not have been surprised if you hit a nasty limit or edge case somewhere. Have a look at #5039 if this would help with your problem, we see this as the better re-implementation of what this could have been.

[maxh]

Have a look at #5039 if this would help with your problem

Yes, that is exactly what we need. I see now that you mentioned it above as well. We'll stay (eagerly) tuned for that -- thanks for an otherwise amazing tool!