Combine instead of inherit

[bilogic]

Love your inheritance approach! After using it, I thought this might be even better

Feature description

The issue is .env keys can be overwhelming, I'm often unsure who owns which entry and their purpose, and there is usually a bunch of them that we just don't touch.

Suggest a solution (Optional)

Instead of inheriting only from 1 parent, let us add several together, I'm thinking of

1. _base_public - these are the default keys provided by the framework we are using
2. _base_ours - these belong to our organization, our packages etc
3. _base_secrets - these typically come from 3rd party, e.g. google tokens etc
4. _base_dev - common keys/values for development
5. _base_prod - common keys/values for production
6. this breaks out the config cleanly
7. I don't think my idea is fully baked yet, very open to discussing
8. And to deal with duplicate keys, in a list of _base_*, the later ones should take priority, same as inheritance, child overrides parent
9. Also, I think it does not make sense to make parents available to the projects, developers outside the system will only see prod, stage and dev instead of all the _base_*
10. Perhaps we could add another setting called must inhert/combine, or the opposite exportable

[bearlike]

I like the layering idea but I am hesitant on this one. Multiple parents would complicate resolution, overrides and cycle detection quite a bit. Leaving it open to think about, no promises yet.

[bearlike]

One more thought. Secret references might already get you most of the way there. A key in prod can be set to ${_base_secrets.GOOGLE_TOKEN}. Cross project works too with ${otherproject.someconfig.KEY}. So one final config can pull from several base configs. You pick which config wins for each key. References are validated at save time and cycles are rejected. The gap is that this works per key. There is no wildcard to pull in a whole base config at once. Still worth a try for splitting secrets into owned groups.

[bilogic]

Ok, thanks for getting back, I feel ${otherproject.someconfig.KEY} could become a vulnerability, I could steal the keys of another project.

Since deleting is now possible, perhaps let me use SSM first, then I will be able to present use cases where inheritance is insufficient.

[bilogic]

The most common problem I face is, a developer created a feature that requires adding new keys, but has no efficient way to let everyone know.

My new insight is, working back from this problem might lead us to a better solution.

1. Perhaps we can tell a project all its known keys, which are optional/required + default values (developer will add new keys here)
2. This will cascade down to all the configs
3. Optional keys may have default values, e.g. STRIPE_TOKEN, value should not be provided, but should also not interrupt when developer is pulling down secrets
4. Still on optional keys, e.g. APP_NAME, every config gets the provided value unless they overwrote it
5. Required keys cannot have default values so that every config (developer) is now forced to acquire their own value, e.g. APP_URL, DB_PASSWORD every config has to provide its own value, if not provided, developer is interrupted when pulling down secrets
6. So the delta in this solution is to add a feature that let us flag keys as optional/required (instead of combine from the OP)
7. I think the above is actually possible to simulate in today's inheritance structure

Let me think more