Skip to content
GitLab

[typescript][angular] basePath through injected config

Closed Administrator requested to merge github/fork/akehir/feature/basePathThroughInjectedConfig into master

Created by: akehir

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
  • Filed the PR against the correct branch: master, 3.1.x, 4.0.x. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

@macjohnny : This resolves https://github.com/OpenAPITools/openapi-generator/issues/282 , implementing my swagger-codegen pull request on the fork.

I notice, that there are a few tests missing, notably the ones I've previously added for angular 6.

CI is here: https://travis-ci.org/akehir/openapi-generator The original PR here: https://github.com/swagger-api/swagger-codegen/pull/8305

Original description of the PR

Instead of using the this.basepath, we use this.configuration.basepath - allowing us to inject a different configuration (after loading a configuration file over http during APP_INITIALIZER). We've been using this setup at a project for a while and it has been working well for us (different api url's in different environments, provided by the webserver on runtime).

This would close the problems discussed here: #3221 (comment) and #7949.

This the distinction to the existing PR #7965 is, that it is not required to generate / handle an observable, but rather just by changing the injected configuration, another basePath would be used. Do you think this would solve your concerns @chrismellard?

Since the rest of the swagger api client is always referring to the this.configuration.{...}, I believe this approach might be more consistent with the general handling of the configuration service.

To keep compatibility with implementations that don't inject a configuration, but just the base path, I set the base path on the internal configuration object to the injected basepath (when they don't exist).