[typescript] Avoid code duplication

[bodograumann]

In #20430 a lot of new code was added in the output. Most of it can be avoided by reusing central functions.

These changed should not change the functionality.
There is however one minor detail that is different now: If _options is given, but without any middleware, the existing middleware is kept. To clear it { middleware: [] } needs to be passed. I think the previous behaviour was an oversight, becacuse all other items fall back properly as well.

• Extract reusable logic into central functions
• Regenerate samples
• Update test dependencies to make them run

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 || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  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*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

CC @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02) @davidgamero (2022/03) @mkusaka (2022/04) @joscha (2024/10)

[joscha]

The diff is hard to check - can we revert the whitespace only and quote changes?

Also, regarding the changed default behavior, did you revert that to the behavior before the change in this pull request or did you just mention it for a follow up? I think we should probably restore it to what it was, and involve the original author and @macjohnny when doing so.
Possibly two PRs, one clean refactor and one restore ot the previous behavior might be good. Don't mind the order.

[davidgamero]

this significantly cleans up the logic.

If _options is given, but without any middleware, the existing middleware is kept.

this was done to preserve backward compatibility with the previous pattern in which the entire Configuration object passed in _options replaced the api's internal configuration. In that scenario, passing an _options with undefined middleware would still result in no middleware.

the default use of the 'replace' middlewareMergeStrategy really only makes sense for middelware values that are arrays, so I'd be in favor of this change to the default behavior.

to be clear, the change is the following:

{middleware: undefined }  // preserves existing middleware

{middleware: []} // replaces existing middleware with empty array, same as
{middleware: [], middlewareMergeStrategy: 'replace'} // same as above since default middlewareMergeStrategy is 'replace'

this would benefit greatly from adding tests to cover both cases here's where i put the current tests

[bodograumann]

You are absolutely right, @joscha. I probably crammed in to much into a single commit in the flow of things.
I can also split up the logic changes into a separate PR and try to do things more clearly.
Are you ok with looking at individual commits? Then I would simply split the whitespace changes into a separate commit.
Also, would you prefer one commit to generate the samples, one sample commit per template change commit or for me to regenerate samples in the same commit as the template change?

@davidgamero Thanks for your support :-) Adding tests is definitely a good idea.
Actually, if I'm not mistaken, originally you could not pass undefined for middleware, so it would always take the new array. Your change to make it merge the configs seemed to suggest that now we should keep the original middlewares if none are given. So I'm glad we are on the same page. 🚀

[bodograumann]

Ok, I now made smaller commits, @joscha . I hope this works for you.
The behaviour should be the same as before, but I inadvertantly fixed one bug and added a test for that:
When no options are given, the static middleware was dropped before. Now it correctly uses the static middleware.

Btw (you probably know this), but there is an option in github to hide whitespace changes.

I'll cerate a separate PR for more refactoring and the behaviour change when options are given, but without a middleware field.