Environment Variables - for mono repo - at the repo, or sub-project level?

[thorwolpert]

Select Release Product

nuxt-base layers in support of the low-volume filings

Summary

Should there be 1 common env file for the whole repo to use, or should it be at the sub-project level?
It could be set on a pre-sub-project level, but this is looking to answer if we can avoid more complexity.

Current mono-repo goals are to service a singular business / partner area.

Consensus

Initial implementation will be to have the envvars at the root level covering all the deployed filings needs.

Basic Example

Defining if the env description is at the root

/devops/vaults.env

versus

/web/{product-A}/devops/vaults.env
/web/{product-B}/devops/vaults.env

Reviewing the current products, they look identical except for NUXT_PUBLIC_BASE_URL which could be fully parameterized.

Motivation

The current CD does not support executing from the root of the repo leveraging the npm workspace definitions dues to where the devops directory lookup is expected. The current CD set the workspace to the sub-project to execute, but this does not leverage the workspace features need to keep the monorepo lean.

Drawbacks

Sub-projects may have envvars that are not used in their project.

Adoption Strategy

There are some legacy layouts / envvar naming being used, so those projects would need to be changed. This does not seem like a significant issue that should affect the final decision.

Future Alignment

Vite is adopting support for monorepos. Its target is to overtake turbo/nx and be package manager agnostic adopting antfu's ni.
Although there is an upcoming vite-environment-api, that looks to be more focused on module developers.
This decision is therefore focused on meeting current needs, and will move to adopt the vite monorepo support as that becomes more prevalent. We do know that those base products heavily use workspaces and changesets, so they align with our current direction nicely.

Unresolved Questions

No response

[kialj876]

I like the idea of having one vaults.env at the root, but it might be good if the CD also checks the sub project for something like 'vaults.overrides.env' so that we can easily override any env variable for a sub project if we need to in the future (i.e. base url, ldarkly, keycloak or something)

[deetz99]

Sounds like a good plan to me

[severinbeauvais]

I like the idea of supporting both but, as a first cut, I think a root-level env file makes sense.

Do we foresee the drawback of perhaps needing to update all products at once if a major key change is needed (eg, as with GCP URLs)? If the products has separate configs then they could be updated independently. This could be mitigated with new keys instead of replacing old keys.

[thorwolpert]

Yeah, that's a good idea. If I'm reading that right, we would use different keys for breaking changes?
I think we're good then to start with a singular root, as we have some options to try out or change as new requirements come in.

[severinbeauvais]

If I'm reading that right, we would use different keys for breaking changes?

Yes.

[deetz99]

Looks like we have an agreement. Can we move forward with this?

[thorwolpert]

Consensus

Initial implementation will be to have the envvars at the root level covering all the deployed filings needs.

Basic Example

Defining if the env description is at the root

/devops/vaults.env