Allow browsers File type for files

[bodograumann]

I changed the HttpFile type to Blob & { name: string } for browser platform and to Buffer & { name: string } for node platform. This is imho more convenient.
The upload tests now work for both default and jquery petstore samples.

There is also a bit of code cleanup included.

Cf. #802
CC @TiFu

[bodograumann]

Seems we are too out-of-date for the pipeline. I guess it is time for merging master again :-D

[bodograumann]

Would it be possible to merge master without squashing? @TiFu
The squashing we did last time makes merging master again really hard.
Or is there a trick I don’t know?

[wing328]

cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02)

[amakhrov]

Not sure I agree that mutating the Buffer is more convenient or even more intuitive than passing a composite of {name, data}.
What is the benefit of this approach?

[bodograumann]

True, for node you could argue this not more / less convenient.
I mostly did it because of the browser platform though.
There you usually handle File objects, which already contain a name.
I'd be happy to hear how you would weigh this.

[TiFu]

This could also be an generator-specific configuration, couldn't it? Just generate the appropriate wrapper ({name, data} composite for anything node, and what is in this PR for the browser) and then internally map this to an appropriate type before doing all the api logic.

[bodograumann]

I could get on board with that, @TiFu. As long as you think that this won't be too much additional complexity.

[TiFu]

Would it be possible to merge master without squashing? @TiFu
The squashing we did last time makes merging master again really hard.
Or is there a trick I don’t know?

You should be able to either git merge master, then resolve conflicts (probably not a whole lot) or git rebase master which rewinds all of our work, then pulls in the commits from master and applies our work again.

[bodograumann]

Unfortunately it is not as simple as that. Cf. https://stackoverflow.com/a/11797964/1534459
By squashing the merge from master into the feature branch, the feature branch now contains a copy of the changes in master.
That means when trying to do any further merge of master into the feature branch or the other way around, the two changes will be in conflict. (Even though they contain exactly the same)

Maybe we should just throw away the history of this feature branch and rebase everything as one commit on master, @TiFu !?

[macjohnny]

@TiFu maybe it would be possible to keep the current typescript-generators and offer the refactored typescript generators as a separate generator, eventually removing the current (old) typescript-generators.

[TiFu]

@bodograumann that's a good point. If you want, I can rebase ts-refactor onto the latest master and force push those changes. You should then be able to fetch the latest ts-refactor and reapply the changes from this PR. Would this work for you?
This should make ts-refactor look like we started working with the latest master.

@macjohnny sounds like a good idea to get a bit more work done on this - before we do this though I would make it absolutely clear that it's an alpha version and there may be breaking changes in the future. I'll also check next weekend what we need to do to reach feature parity with the already implemented generators (jquery and ts-fetch)

[bodograumann]

@TiFu That sounds good. I can probably cherry pick this PR quite easily.

[TiFu]

@bodograumann Rebasing took me a bit longer than I expected, but I hope everything went okay. The rebased branch will be on typescript-refactor-master until I can make sure everything went right and I didn't delete any changes compared to typescript-refactor. I'll try to verify this tomorrow or the day after.

This rebase also removes the changes introduced in the squashed master merge commit - in the future git merge master without --squash (outside a PR! so that git retains knowledge about common ancestors) should prevent this issue as far as I understand.

[bodograumann]

From regenerating the samples, I think in 7a372ac you missed the changes to DefaultCodegen.java, @TiFu.

[bodograumann]

This is the diff:

diff --git a/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java b/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java
index 914c59facc..6faccf5c43 100644
--- a/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java
+++ b/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java
@@ -3327,7 +3327,8 @@ public class DefaultCodegen implements CodegenConfig {
             op.examples = new ExampleGenerator(schemas, this.openAPI).generateFromResponseSchema(exampleStatusCode, responseSchema, getProducesInfo(this.openAPI, operation));
             op.defaultResponse = toDefaultValue(responseSchema);
             op.returnType = cm.dataType;
-            op.hasReference = schemas.containsKey(op.returnBaseType);
+            op.returnFormat = cm.dataFormat;
+            op.hasReference = schemas != null && schemas.containsKey(op.returnBaseType);
 
             // lookup discriminator
             Schema schema = schemas.get(op.returnBaseType);

If you like, I can create a PR for typescript-refactor-master, but it will probably be faster if you do the change yourself.

[TiFu]

Thanks! I readded the change. I'll check back in ~30 minutes to see if CI still complains or if it's fine.

[bodograumann]

I have kept the existing object type for the node platform now and only applied the changes for browsers.
Also the merge base is now typescript-refactor-master.

@TiFu

[TiFu]

Perfect, looks good to me.

Thank you for the PR which has been merged into ts-refactor-master.