Optional packages still require environment variables to be set

[damien-schneider]

Describe the bug
Some environment variables for optional integrations (like Stripe) are still treated as required.
Because of this, the app fails to start if these variables aren’t defined — even when the corresponding integration isn’t used.

next-forge version
I am using version v5.2.0

To Reproduce
Steps to reproduce the behavior:

Create a new next-forge project (v5.2.0)

Skip setting any Stripe stup & environment variables

Run pnpm dev

See the startup error complaining about missing environment variables

Expected behavior
The project should start successfully even when optional integrations aren’t configured. Or if not, it should be written in the documentation how to disable them.
Environment variables for optional packages should either be optional or allow empty strings by default. And it should work as is.

[piusmons]

@damien-schneider encountered this bug as well. I am from Philippines where Stripe isn't supported. As such I do not need this integration.

Aside from that, I do not want to use all of the other integrations just yet.

Running pnpm dev I get startup errors complaining about missing environment variables.
Have you been able to figure out how to disable these integrations?

[damien-schneider]

Hey @piusmons, same here. After running into too many errors while trying to disable some optional integrations, I abandoned the setup for now. I’ll wait for this issue to be resolved and then try again.

[AurelienBdl]

Also encountered this bug

[juanignaciomolina]

Same here. Seems like the validations that check for the env vars strings starting with something that looks like the right key might be a cause for it not detecting properly when a key is left empty intentionally.

For example in the Google Analytics keys.ts file, if you remove the .startsWith("G-") then it will stop throwing an error when it is empty (even if it was marked with an .optional() too)

[piusmons]

Unfortunately decided to go with a different template. Less thorough and "production-grade" than next-forge but perfect for solo devs like me.

Will still keep an eye on this project though

[midego1]

Trying to fight with this for the past 3 hours, what a painful experience is this setup.

[midego1]

I give up

[kamil-homer]

I don't have my .env files handy right now, but the quick workaround is to mock the API keys. The validation for most of them just checks if they are defined in api/env.local,app/env.local, and web/env.local. The easiest way to mock them would be to start with a pattern: the API key for service XY starts with xy_. This should be enough to pass validation - or in some cases, you might get an error message saying, XY API keys must start with....
I will try to fix the validation in the upcoming days.

[midego1]

I think this whole setup is broken, lot's of issues created.

[piusmons]

@kamil-homer Suggestion, just put these mocked values as the default so people who use this template can start and go. Anyone who wants to actually use a specific package can just activate it by changing the env var to the right value

Turned me off when I realised i had to scour every .env file and mock everything and check if I put the right "starts with" value. It's tedious and prone to frustrating mistakes.

[midego1]

It also does not work with mock value :)

[piusmons]

Is there any way at all for the whole monorepo to just utilize one .env file in the root directory?

I would have had no qualms signing up for every API key required if it were the case...

[midego1]

Even if you do it fails to build in the end

[gsj55cbdigital]

I got hung up on fighting the environment variables even when I went through and configured every SaaS provider. Ultimately couldn't hit the ground running and abandoned using this for now.