Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • O openapi-generator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,476
    • Issues 3,476
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 402
    • Merge requests 402
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenAPI Tools
  • openapi-generator
  • Merge requests
  • !11362

[TypeScript-fetch] expose the path of each method (e.g. testing purposes)

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Administrator requested to merge github/fork/jverhoelen/typescript-fetch-expose-apimethod-path into master Jan 20, 2022
  • Overview 0
  • Commits 1
  • Pipelines 1
  • Changes 38

Created by: jverhoelen

Our team uses the typescript-fetch generator and has a lot of unit tests which mock HTTP responses that the generated client executes. In order for tests to know the HTTP paths to mock it would be helpful to let the generated API project also expose the paths of the API methods.

The most simple idea we came up with is to simply offer public members in the TypeScript API classes per API method. This makes it easy to use in case you need it but still optional and non-intrusive.

I didn't create an issue for this change because it's no misbehaviour and at this point I could find any downsides of the change. Let me know if this is something that is really necessary.

I re-generated all sample clients for TypeScript-fetch (checked in), started the petstore API locally and ran the integration tests locally.

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package 
    ./bin/generate-samples.sh
    ./bin/utils/export_docs_generators.sh
    Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
  • File the PR against the correct branch: master (5.3.0), 6.0.x
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. (@amakhrov ping)
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: github/fork/jverhoelen/typescript-fetch-expose-apimethod-path