-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restructure TypeScript Node generation into separate files (PHNX-1041) #363
Restructure TypeScript Node generation into separate files (PHNX-1041) #363
Conversation
2022a20
to
2cda3f0
Compare
@gbrown-ce thanks for the PR! will have a look at it soon |
86caebf
to
0f4b3ea
Compare
@macjohnny thanks! And don't be afraid of the ~50 files changed. Only the first 7 are really changes. The rest are just generated samples. |
0f4b3ea
to
0372e9e
Compare
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny I believe the necessary CI step has passed here and this should be ready for review/merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although I haven't tested it, the changes look good. I think this is a nice improvement.
@gbrown-ce can you confirm that you generated your project with this code and everything worked correctly?
|
||
@Override | ||
public String getSchemaType(Schema p) { | ||
String openAPIType = super.getSchemaType(p); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you please explain in the comments why these type mapping methods are needed / what they do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@macjohnny I believe the idea for this is to allow the "Buffer" type to be used properly. Initially when I did this, it tried to import it as ./models/Buffer which is wrong. There is similar work done in the angular client for the "Blob" type.
return languageSpecificPrimitives.contains(type); | ||
} | ||
|
||
private boolean isLanguageGenericType(String type) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you give an example input in the method docs?
I guess you expect something like Array<string>
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@macjohnny I'm not sure of the exact purpose of this one, again, it is taken from the angular generator. But yes, I'd assume you're correct
|
||
private String getPackageRootDirectory() { | ||
String indexPackage = modelPackage.substring(0, Math.max(0, modelPackage.lastIndexOf('.'))); | ||
return indexPackage.replace('.', File.separatorChar); | ||
} | ||
|
||
private String getApiFilenameFromClassname(String classname) { | ||
String name = classname.substring(0, classname.length() - "Api".length()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about setting the "Api" suffix as a member property, which later could possibly be customized with a configuration option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can move that
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx |
@macjohnny yes I tested it with my own project and it works great. |
@macjohnny I have updated the PR with your requested changes. Even went so far as to add the api suffix as a parameter. I also went through and ran all 5 of our swagger documents through it and the newly generated clients worked perfectly. |
@gbrown-ce thanks for the changes, I think now it should be good to go. |
6abb83f
to
5603988
Compare
@macjohnny I'm about to head on a week long vacation. Can I trust you to get this merged before I get back? That'd be a huge help. |
@gbrown-ce This PR will eventually be merged by @wing382, I am not able to do that. |
Anyway, you could also temporarily build from your branch and publish the artifact in your local repository |
@macjohnny good to know. Can you take a look @wing328 ? As far as local artifacts, yes I could do that (and have for testing), but we are integrating our Jenkins pipeline with the openapi-generator-cli docker image, so to be fully finished on my end, I need to final code to be in (or make my own docker image, which I'd rather avoid) |
Oh and the failures in the Travis build seem to be related to a problem that already exists in master. |
Please ignore the failure related to rust-server for the time being as the failure is due to CI pulling a newer version of the dependency. |
For "/" in the file path, please replace it with |
If I understand the PR correctly, this enhancement is a breaking change without fallback so the PR should target the |
This change should not be applied, since the imports in typescript files always use |
this PR could be turned into a non-breaking change by simply re-exporting the files in the @gbrown-ce would you like to apply this change? |
edfa7d2
to
5d5929b
Compare
@macjohnny Just got back from vacation and made the suggested changes. Just waiting for CI to run through. |
5d5929b
to
eebcdab
Compare
@macjohnny @wing328 looks like CI is happy. Do the changes look good to you guys? |
@@ -110,10 +211,12 @@ public void setNpmRepository(String npmRepository) { | |||
@Override | |||
public void processOpts() { | |||
super.processOpts(); | |||
supportingFiles.add(new SupportingFile("api.mustache", null, "api.ts")); | |||
supportingFiles.add(new SupportingFile("models.mustache", modelPackage().replace('.', File.separatorChar), "models.ts")); | |||
supportingFiles.add(new SupportingFile("apis.mustache", apiPackage().replace('.', File.separatorChar), "api.ts")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't there a collision for the destination filename api.ts
, since both apis.mustache
and index.mustache
are generated to api.ts
?
anyway I would suggest to rename api.mustache
to api-single.mustache
and apis.mustache
to api.mustache
in order to avoid confusions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No collision there, the apis.mustache goes into a subfolder, but yes, I can clean that up a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to go with this:
api-all.mustache = all of the apis re-exported together (output as /apis/apis.ts)
api-single.mustache = single api (output as /apis/{name}Api.ts)
api.mustache = entry point (output as /api.ts to prevent breaking change)
I think this should avoid any confusion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@macjohnny done. Just awaiting CI again
@gbrown-ce could you please merge the current |
@macjohnny: thank you a lot for the coordination and all the feedback on this PR. It is nice that you found a way to make this a non-breaking change. With this it can be merged into |
Motivation ------------- The current version of TypeScript node generation puts all of the generated code in a single file. This causes issues when using inheritance as each model may depend on another and they must be included in the proper order. Modifications ------------------ Split the mustache template into pieces so that it can properly separate the models and different apis to allow for proper compilation. I also removed some compiled JS files from the petstore example generation that shouldn't have been in the repository.
- Set up the API suffix to be a member variable for future parameterization - Deleted some more compiled files from the sample directory
f24195a
to
f2e1c02
Compare
@macjohnny @wing328 I sorted out the merge conflicts. Ready to merge into master. |
Maybe the change is important enough to be mentioned in the Migration guide between OpenAPI-Generator versions. => This can be filed as a separated PR. |
PR checklist
./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\
.master
,3.1.x
,4.0.x
. Default:master
.Description of the PR
The current version of TypeScript node generation puts all of the generated code in a single file. This causes issues when using inheritance as each model may depend on another and they must be included in the proper order.
Split the mustache template into pieces so that it can properly separate the models and different apis to allow for proper compilation. I also removed some compiled JS files from the petstore example generation that shouldn't have been in the repository.
Related issue: #350
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny