Add option to pass in a custom handlebars template to generate the service files

[mb21]

Adds the --serviceTemplate option, which can be used to pass in a custom handlebars template to generate the service files.

This is a rough draft PR with what we're currently using, if you're interested in merging this, can be refined.

Solves #1191, #703 (comment) and potentially a big number of other customization requests.

We're currently using this with this template:

{{!-- this file is based on https://github.com/ferdikoomen/openapi-typescript-codegen/blob/75a648cc4e2e90cf78b26fcfe8b641797d82ad86/src/templates/exportService.hbs --}}
/* tslint:disable */
/* eslint-disable */
{{#if imports}}
{{#each imports}}
import type { {{{this}}} } from '../models/{{{this}}}';
{{/each}}

{{/if}}
import { Result } from '@/definitions/BasicTypes';
import { Opts } from '@/helpers/http/http'
import { openApiRequest } from '@/helpers/http/openApiRequest';

{{#each operations}}
/**
{{#if deprecated}}
  * @deprecated
{{/if}}
{{#if summary}}
  * {{{escapeComment summary}}}
{{/if}}
{{#if description}}
  * {{{escapeComment description}}}
{{/if}}
{{#unless @root.useOptions}}
{{#if parameters}}
{{#each parameters}}
  * @param {{{name}}} {{#if description}}{{{escapeComment description}}}{{/if}}
{{/each}}
{{/if}}
{{/unless}}
{{#each results}}
  * @returns {{{type}}} {{#if description}}{{{escapeComment description}}}{{/if}}
{{/each}}
  */
export const {{{capitalize name}}} = ({{>parameters}}fetchOptions?: Opts
): Promise<Result<{{>result}}>> => {
  return openApiRequest({
    method: '{{{method}}}',
    url: '{{{path}}}',
    {{#if parametersPath}}
    path: {
      {{#each parametersPath}}
      '{{{prop}}}': {{{name}}},
      {{/each}}
    },
    {{/if}}
    {{#if parametersCookie}}
    cookies: {
      {{#each parametersCookie}}
      '{{{prop}}}': {{{name}}},
      {{/each}}
    },
    {{/if}}
    {{#if parametersHeader}}
    headers: {
      {{#each parametersHeader}}
      '{{{prop}}}': {{{name}}},
      {{/each}}
    },
    {{/if}}
    {{#if parametersQuery}}
    query: {
      {{#each parametersQuery}}
      '{{{prop}}}': {{{name}}},
      {{/each}}
    },
    {{/if}}
    {{#if parametersForm}}
    formData: {
      {{#each parametersForm}}
      '{{{prop}}}': {{{name}}},
      {{/each}}
    },
    {{/if}}
    {{#if parametersBody}}
    {{#equals parametersBody.in 'formData'}}
    formData: {{{parametersBody.name}}},
    {{/equals}}
    {{#equals parametersBody.in 'body'}}
    body: {{{parametersBody.name}}},
    {{/equals}}
    {{!--
    {{#if parametersBody.mediaType}}
    mediaType: '{{{parametersBody.mediaType}}}',
    {{/if}}
    --}}
    {{/if}}
  }, fetchOptions)
}

{{/each}}

[lgtm-com]

This pull request fixes 4 alerts when merging b24a97c into abab307 - view on LGTM.com

fixed alerts:

• 4 for Polynomial regular expression used on uncontrolled data

[josh-hemphill]

Can this be moved out of draft?
I'm needing to try and use custom templates to generate options for a custom client, and probably base it on this, but add options for the other main templates.

[mb21]

If there is interest by @ferdikoomen to eventually merge it, I might put in the time to clean up the PR... but of course feel free to cherry-pick commits etc.

[gersongoulart]

Dear @ferdikoomen, @mb21 and @josh-hemphill, I hope you're all doing well. I noticed a shared need for custom Handlebar templates, and I found myself in a similar situation. However, I required additional flexibility for my specific use case. In response, I've submitted a "competing" Pull Request, presenting the simplest solution I could come up with that allows customization of all templates and partials across the system. I would sincerely appreciate your insights and feedback on these changes, in case there's anything I can do to enhance this implementation. Thank you in advance for taking the time to review and provide your input.

[josh-hemphill]

One thing I discovered was that when some of the current templates get called, they're not provided enough properties of the context to be useful for much customisation, I had to add the additional context to the template calls in to get any of my stuff working; it doesn't seem to hurt anything to have extra context provided to the default templates.

[gersongoulart]

@josh-hemphill I agree that enhancing the context passed to templates is good for customization. I do believe implementing this in a separate pull request would be a better approach to keep Issues/PRs organized and easy to understand; facilitate unit testing, ease code review and minimize risks.