Add API version value to configuration #73
Conversation
By using a new file `api_versions.txt` that simply contains all the valid API versions separated by comma, we are able to generate our client taking into account these versions, allowing a new option on each endpoint to specify the version and also adding a new method to the client that allows to set the version for the whole client.1 Signed-off-by: Ruben Aguiar <[email protected]>
raguiar9080
requested review from
jstasiak,
rbruggem,
charcarr,
0bex0 and
jasharifestina
raguiar9080
changed the title
Our new base generator has introduced [^1] capabilities to allow using a specific API version via the `options` field. This adapts the library to correctly use this new option. Keep in mind that there will be more changes introduced when the base generator is shipped, the dependency here upgraded and everything regenerated. For now the PR contains the required changes on the actual library to allow the new field to be used. [^1]: lune-climate/openapi-typescript-codegen#73 Signed-off-by: Ruben Aguiar <[email protected]>
Reading from a file is clunky and weird. Just add another parameter to the application. Signed-off-by: Ruben Aguiar <[email protected]>
Signed-off-by: Ruben Aguiar <[email protected]>
Are you referring to the major version that is part of the path of the date-version in the header? |
No, this refers to the calendar versions provided via header. I'll reword 👍 |
- Remove `currently` since it adds nothing - Make sure we always refer to these as calendar versions. Signed-off-by: Ruben Aguiar <[email protected]>
|
Everything has been reworded. I'll wait for lune-climate/lune-ts#665 (comment) to be resolved before merging since it will affect necessary changes here. |
There was a problem hiding this comment.
Approving but I think #73 (comment) is important to avoid confusion.
We have decided to not have per-endpoint versions nor client wide versions. Instead, we will simply have a single version for all the types that needs to be specified in the request as a header. Rename the parameter to instead receive a single API Version which is stored in the `luneClient` configuration, which can be used by `lune-ts` to send via a header. Signed-off-by: Ruben Aguiar <[email protected]>
Signed-off-by: Ruben Aguiar <[email protected]>
Signed-off-by: Ruben Aguiar <[email protected]>
raguiar9080
changed the title
raguiar9080
changed the title
raguiar9080
deleted the
ruben/lun-3701-create-api-scaffolding-prototype
branch
Our new base generator has introduced [^1] capabilities that require an API version to be set which is added in the client configuration. This version is now fetched and used by the library to pin `lune-ts` to a specific version of our API using the `Lune-Version` header. Updating the base generator and regenerating comes with an extra notice in the file but no other functional changes besides the ones this PR pretends to introduce. [^1]: lune-climate/openapi-typescript-codegen#73 Signed-off-by: Ruben Aguiar <[email protected]>
Add a new required parameter to the application that specifies the API calendar versions that is to be used. This value is currently added to the configuration of the generated client
luneClient.tsso it can be used later. The goal is to have all requests inlune-tsadd this value in theLune-Versionheader so the library works on a single version, always matching the code with the types in place.