My proposals

1. Add a syntax in Prisma Schema Language for setting a default value if env variable was empty. e.g.

datasource db {
  provider = "postgresql"
  url = env('POSTGRES_URL') || "postgresql://dev@localhost/testdb"
}

2. As a better option add support for schema definition in JavaScript/Typescript (e.g. schema.prisma.js)

Why I think creating a new schema language isn't a good idea?

• Please re read your article on the problems of schema first development.
• I worry that in time you reach the same conclusion and you end up with a schema language that tries to solve everything but is not as good as a real programming language.
• I think having a real general purpose programming language at your disposal is always a good idea. (take Webpack config or many other tools for example)
• I understand that Prisma is a cross language tool (Go driver for example) but it is also written in JS and Generator and Lift need node to run. So I see no harm in having a schema.prisma.js option.

What are the use cases for these?

I’m struggling to add Prisma 2 to my development workflow.
I have a complex NodeJS server that connects to some DBs and outside services. We try our best to keep initial configuration for new developers as simple as possible (setup everything in the first npm run dev).
We use docker to initialize and run the DBs and external services and setup some default credentials for dev databases.
In the dev server we set the same default credentials for our DB connectors so new developers don’t have to worry about DB config at all.
The current url system for Prima Schema Language only accepts environment variables. It is a good thing for production but not the dev env.
Using .env file is not a good option for us as each new developer should create it and add the default configs to it.