feat: (enhancement) Seeds and Scripts

[mthomps4]

Changes

• Enhanced organization for Seed pattern (Dev vs Prod)
• One-off Script Pattern
• Readme
  https://github.com/echobind/bisonapp/blob/3f9ff1bec88dcb1cdfa696f64a09f2f456960858/packages/create-bison-app/template/prisma/SeedsAndScripts.md

Checklist

• Requires dependency update?
• Generating a new app works

[kgajera]

A couple thoughts:

• Instead of APP_ENV, would it be better to use NODE_ENV so we don't have to introduce a new variable?
• run:script
  • I'm wondering if this is worth adding since it just runs yarn ts-node? If we didn't have yarn run:script {filename}, you would run yarn ts-node prisma/scripts/{filename}. Just trying to figure out if run:script provides enough convenience to keep it.
  • If we do want to keep it, I think this should be renamed, probably prefixed with db. I think the current name suggests that I can run a script in the root scripts folder: https://github.com/echobind/bisonapp/tree/canary/packages/create-bison-app/template/scripts

[kgajera]

We should update this to use cross-env so it will work on Windows.

Similar to this script: https://github.com/echobind/bisonapp/blob/canary/packages/create-bison-app/template/package.json.ejs#L13

[mthomps4]

Updated c0e2f58

[kgajera]

The prisma configuration already exists here so one of them should be removed: https://github.com/echobind/bisonapp/blob/canary/packages/create-bison-app/template/package.json.ejs#L131

[mthomps4]

Overlooked, thanks!

[mthomps4]

Updated c0e2f58

[mthomps4]

@kgajera

Instead of APP_ENV, would it be better to use NODE_ENV so we don't have to introduce a new variable?

I don't like using NODE_ENV, there are times in deployment environments where NODE_ENV is production, even though the environment may be Staging, Test, Demo, etc.

run:script

I don't think this should be prefixed with db: while that may be 90% of the use case, they can be anything needed for the app. I'd rather move the scripts folder if that helps.

You are right, we can run yarn ts-node {file}, I wasn't sure if the semantic script would help encourage a pattern.

[code-jenn-or]

I too do not like using NODE_ENV as I have WAY too often seen it say production when I'm not actually in production, I think it is better to be explicit even if it is an extra environment variable. These can also help with things like sentry reporting where you can split out the "environments" with tags in the same project so it has more uses there.

I also like the pattern of run:script because I often think people get caught up in not remember the ts-node or the "how" they can execute something, if we create the repeatable convenience it will be clear. I think this is looking great.