Support for custom CLI parameters
tobiasqueck opened this issue · 5 comments
Is your feature request related to a problem? Please describe.
When I need to run e.g. ui5 serve with different configurations, I am currently forced to create multiple ui5*.yaml files. In some cases, I need exactly the same configuration except one value is different. The overhead of maintaining multiple files for that is increasing the costs of maintaining a UI5 project.
Describe the solution you'd like
Allow the usage of custom CLI parameters that are accessible in my middleware/task e.g. I would like to call ui5 serve --debug --magic 42 and in my middleware I have access to e.g. this global configuration as e.g. object
{
debug: true
magic: '42'
}Describe alternatives you've considered
I could also solve the same problem, if it would also be possible to provide the configuration not as yaml but as js file. Then, I have all the flexibility needed to create inheritance between configs or custom creation of the config based on other parameters.
Additional context
No
Have currently the same problem and also did not find a better solution with multiple yaml files.
Are there any plans to improve the current process as I don't see any further feedback here?
We discussed inheritance between yaml files before and I still think it's an obvious solution when looking at current projects with 3+ yaml files all containing redundant information. So I'm all up for realizing that.
Regarding custom CLI parameters I'm wondering how this would be different from using environment variables as described in #935?
Instead of ui5 serve --debug --magic 42 you would write DEBUG=true MAGIC=42 ui5 serve. What am I missing?
@RandomByte the idea of #935 is to have a consistent handling of env variables that the user explicitly declares in the yaml. The idea of this feature is that the middleware owner defines parameters that a user can use to overwrite yaml settings.
Nevertheless, I agree, with #935 in place, using DEBUG=true MAGIC=42 ui5 serve would solve the same problem and be even more flexible. So, please go ahead and implement #935 and at least I won't need this one anymore.
PS: what about my suggested alternative? Allow defining ui5.js? That would be the most flexible.
Alright, thanks for confirming 👍
I could also solve the same problem, if it would also be possible to provide the configuration not as
yamlbut asjsfile. Then, I have all the flexibility needed to create inheritance between configs or custom creation of the config based on other parameters.
I think inheritance between ui5.yaml configuration files should be a standard feature. And I expect this to be generally easy to implement in UI5 Tooling. I don't see why we should push this feature into the responsibility of individual project's configuration files.
What do you think? Or is there something else you would like to solve as well using a ui5.js configuration file?
One of my favorite middlewares (https://github.com/SAP/open-ux-odata/tree/main/packages/ui5-middleware-fe-mockserver) has a not well documented feature allowing to configure it using a js file. I use it heavily for test environments because I just drop metadata.xml files into a folder and my script automatically generates the corresponding configuration for the middleware.
With a ui5.js I could do the same for any middleware.