Shorthand configuration

[jeswr]

Feature description

Now that https://communitysolidserver.github.io/configuration-generator/v6/ exists I feel that it would be quite useful to make that config generation logic a feature of startup, where the values entered in the UI can instead be part of this JSON config for the CSS and the output config is just generated internally to startup the server.

For instance a CSS instance with ACP might have a config looking like

{
  "port": 3001,
  "loggingLevel": "error",
  "authorization": "acp"
}

[joachimvh]

I get where you're coming from, but this is a not a trivial problem for several reasons.

The JSON config above allows users to set CLI parameters through their package.json instead of through the CLI. To add what you suggest either all options from the configuration generator would have to become CLI parameters, or internally we would have to differentiate between them.

No matter which we pick, one of the first issues is that to parse CLI parameters we already need to have a Components.js configuration, as what the CLI parameters are and how they should be interpreted is also defined in the config. But the authorization parameter in your example above would require us to modify the configuration after we already did something with it. Technically this is not impossible since internally we do 2 Components.js runs (one for the CLI, and then one to insert the variables that we got from the CLI into the same config), but that would probably drastically complicate things.

Another thing would be how to interpret it. In your instance you give the server a config, default.json since the config parameter has no value, but then also tell it to replace the authorization system defined by that configuration. If the input config conforms to a standard expected format we could sort of make that work, first do JSON parsing to find the imports, replace the relevant ones, and then feed that into Components.js. But if the input config diverges a bit from the expected format there would be now way to do this. There would also be no way to take into account overrides or other things defined in the base config.

All the logic of how options map to specific configuration formats are also solely in the configuration generator repository, the CSS repo has no idea about this. So these would then have to be merged. The configuration generator codebase is of much lower quality than this one, and has drastic architectural changes if I think of something new, which would make it not that great of a fit to be in here. Having it separate and work as it currently does also allows me to move much faster in that repo if changes are needed.

One thing that could be done and would be much easier would be to add a tool to the config repo that parses a JSON file from the CLI with the necessary options, and outputs a valid CSS config. This could then potentially be chained with a script to feed it into CSS. That would be an issue for the generator repo then.