npm run dev fails in new t3-app due to missing DATABASE_URL

[c-ehrlich]

Describe the bug
npm run dev fails in a new t3-app because it's missing the DATABASE_URL environment variable. However the default database is sqlite, which doesn't need that environment variable.

To Reproduce
Steps to reproduce the behavior:

1. Create a t3-app that includes Prisma
2. yarn dev

Expected behavior
Not sure! Maybe this is ok because we assume that anyone who uses Prisma will want to switch away from sqlite and thus needs a database url? However I don't think it's a great experience - the first thing I want to do after initializing an app is start the dev server and check that everything installed fine, which this prevents.

Would be happy to hear what others think the expected behavior should be.

Screenshots

[AdamHolwerda]

Works after renaming .env-example to .env - agree with the expectation of having a running app example after doing the CLI steps, and also I like the environment variables pattern.

What if the last step of the CLI asked you to enter values for the whatever .env variables aren't already pre-populated and wrote a .env file?

[juliusmarminge]

The reason it fails is you need a .env file as Adam pointed out. We could maybe rename the .env-example to .env and that way it would start out of the box?

Fwiw, This is what we do in our CI to get a working build in there.

[c-ehrlich]

The reason it fails is you need a .env file as Adam pointed out. We could maybe rename the .env-example to .env and that way it would start out of the box?

Fwiw, This is what we do in our CI to get a working build in there.

That seems like a reasonable solution.

Requiring a db url string despite sqlite not actually using it still isn't ideal, but I also can't think of a better solution so maybe this is a good way to go for now.

[ochicf]

IMHO the scaffolded project should be able to run in dev mode just after it's creation, so +1 in having the .env scaffolded aswell.

Also I haven't really used prisma, but could it be possible for the initial DATABASE_URL be defined in the .env pointing to the sqlite local file? That would hint the user that sqlite is being used by default in dev, but maybe an additional comment could be added.

Note that this would also serve as an example to users that they should NOT hardcode the database url in the schema.prisma file as it's currently done with the sqlite db.

Examples:

// schema.prisma

datasource db {
    provider = "sqlite"
    url      = env("DATABASE_URL")
}

// .env

# Prisma
DATABASE_URL="file:./db.sqlite" # <- if changing provider, remember to update `/prisma/schema.prisma`

[juliusmarminge]

Requiring a db url string despite sqlite not actually using it still isn't ideal, but I also can't think of a better solution so maybe this is a good way to go for now.

Not sure if file:./db.sqlite is a valid Zod url? If it is we could have that as the default DATABASE_URL?

// schema.prisma
datasource db {
    provider = "sqlite"
    url      = env("DATABASE_URL")
}

# .env-example
# Prisma
DATABASE_URL=file:./db.sqlite

// installers/envVars.ts
await Promise.all([
  fs.copy(envSchemaSrc, envSchemaDest, { overwrite: true }),
  fs.rename(envExample, envDest),
]);

EDIT: @ochicf beat me to it ;)

[c-ehrlich]

I like this a lot. If it doesn't pass the zod check, we could add .or(z.literal('file:./db.sqlite')) to the schema, which I think shouldn't mess up the type safety?

[ochicf]

I'm not proficient with zod, but could it be a more relaxed check to allow strings starting with file: in case consumers want to change the path or if any other provider uses local urls?

Not sure if this would have some side effects (ex: if the file is gitignored)

[juliusmarminge]

Not sure if file:./db.sqlite is a valid Zod url?

Just checked and seems to validate just fine.

[c-ehrlich]

I can implement this, but would probably wait until I see what happens with #205 to avoid a potential merge conflict

[c-ehrlich]

fixed with #222