WIP rfc: unified-configuration

[siddhantk232]

I have proposed adding the least amount of changes that should give us what we want.

I thought a bit about security and other things too but nothing compelled me to change or add to the existing proposal.

Let me know if I missed anything @amitu and @Arpita-Jaiswal.

[vercel]

@siddhantk232 is attempting to deploy a commit to the fifthtry Team on Vercel.

A member of the Team first needs to authorize it.

[amitu]

One question missing is what about recursive configurations? Eg

A -> B -> C (with config)
A -> C (with config)

What do we see in C/-/config, values provided by A or B? One way to answer would be that all configurations are always in A/FASTN.ftd since A is the main package. But how does A know C has to be configured if A did not directly import C? Other is to say what you see in C/-/config depends on who is seeing.

@Arpita-Jaiswal, @siddhantk232 what do you think?

[siddhantk232]

One question missing is what about recursive configurations? Eg

A -> B -> C (with config) A -> C (with config)

What do we see in C/-/config, values provided by A or B? One way to answer would be that all configurations are always in A/FASTN.ftd since A is the main package. But how does A know C has to be configured if A did not directly import C? Other is to say what you see in C/-/config depends on who is seeing.

@Arpita-Jaiswal, @siddhantk232 what do you think?

I am assuming A, B and, C are packages where A -> B -> C means A imports B which imports C?

I think importing C/-/config should be only allowed inside C.

C's config will be a Map<String, ftd::Value> which is made by merging the values passed to it by fastn.dependency and it's values in FASTN.ftd. Am I making sense?

[amitu]

It being only allowed in C is not the issue, if two different values have been passed to C, one from A and another from B, what does C see?

[amitu]

The only thought I am getting to resolve this is to say package confirmation variables are only available to fastn.app and fastn.auth packages and not to regular dependencies, and they are to only live with theme and explicitly passed variables via inherited.

@siddhantk232 @Arpita-Jaiswal

[amitu]

@siddhantk232 checkout the latest discussion I have written: https://github.com/orgs/fastn-stack/discussions/1477

Seems to solve all the concerns, and is also not much work implementation wise.