Allow addition of command line arguments for generated code

[jaypatrick]

It would be nice if we could specify (or override the default) command line arguments. Specifically in this case, the Kiota generator so that parameters like --backing-store|-b can be added to the generated code. Or, provide UI elements in the options page to provide the parameters (e.g. a checkbox for bools like backing-store, etc).

Or, generate the CLI string and store it as a local file (add to gitignore) that can then be used to execute the generate command w/ the various arguments. There are a lot of Kiota CLI switches that are very useful, but the approach this package takes is a one-size-fits-all, which isn't flexible enough for most dev scenarios.

[christianhelle]

@jaypatrick you can update the kiota-lock.json file added to the project when you generate code using Kiota from the VS extension

When you have a kiota-json.lock file, you can right click on it and generate code

[jaypatrick]

I did see in the code that it would honor settings in the kiota lock file, but I was unable to ascertain if editing the kiota lock file was persistent, or does the kiota lock file get regenerated if updated from an openapi.json file via Url? I'm wondering what happens if the remote openapi.json file's spec gets updated, e.g. a minor revision that changes the signature of public interfaces, or even a major release from v1->v2, and thus the client libs need to be regenerated. It would be nice to not have to go back and update all the individual switches, thought there aren't that many so it probably wouldn't be too hard to write pipeline code that reads the existing settings, then adds them back to the generated kiota lock file.

Or would the workflow be like this:

• Create a new project, right click, add, REST Api gen, input the swagger url, generate via Kiota
• Update the lock file manually (either via hand or pipeline code)
• Regenerate the code as-needed locally
• Monitor remote openapi spec for changes, and when a new version is released, regenerate and then merge into existing code

FWIW I've started a new branch from the fork I did and I'm adding code/gui support for --backing-store|-b but if it's never used I won't submit a pull request unless you think the addition of a checkbox for backing-store adds value. Big picture I was thinking of providing the user with a text box within which they can define their own CLI commands to be added to the generation process, e.g. just underneath the text box where the user defines the class name to use.

LMK if the pull request would add value. No worries if it doesn't :-) I'll just merge updates back into my fork from your repository as needed. Really awesome tool btw, I've used it a lot in the past (since the VS2017 days), just never with Kiota. Keep up the great work.

[christianhelle]

I don't think anyone uses this feature. It's been there since Kiota started producing the kiota-lock.json file upon code generation. Let me see if it even still works

[jaypatrick]

I don't think anyone uses this feature. It's been there since Kiota started producing the kiota-lock.json file upon code generation. Let me see if it even still works

Are you speaking specifically to the --backing-store option? Or other CLI switches in general? Is there any specific reason why backing stores is rarely used? I'm fairly new to Kiota in general, the project I'm working on is my first time w/ Kiota specifically. Longtime swagger/openapi user, but I like Kiota's design.

[christianhelle]

Ok, using the kiota-lock.json file will generate code "on the spot" in the structure that Kiota uses. The VS extension would normally merge all the code into a single file and store it as a code-behind file in the project

[jaypatrick]

Thanks for the updates, I appreciate it.