Open haydenbleasel opened 4 hours ago
I'd suggest splitting into two categories: core and optional (or enhanced, advanced, or something different).
For example, auth and Prisma/database are both core - you can't build a SaaS product without them. But analytics and payments aren't needed to bootstrap a new project - you would enable them later.
Agreed. Another good solution would be to have the env variables for non core packages stored in the package themselves and have the packages themselves feature toggled. This would be more work though
The reliance on 30ish environment variables makes next-forge difficult to spin up quickly. I originally decided to implement it this strictly to avoid production errors when missing env vars.
I'm thinking it might be better to make them optional and have the existence of the key affect whether the feature is "enabled" or not. Open to thoughts and suggestions on this one.