-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[typescript] feat: Add typescript licenseName option #19888
[typescript] feat: Add typescript licenseName option #19888
Conversation
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.
Nice one!
@@ -71,6 +71,7 @@ public Map<String, String> createOptions() { | |||
.put(CodegenConstants.LEGACY_DISCRIMINATOR_BEHAVIOR, "true") | |||
.put(CodegenConstants.DISALLOW_ADDITIONAL_PROPERTIES_IF_NOT_PRESENT, "true") | |||
.put(CodegenConstants.ENUM_UNKNOWN_DEFAULT_CASE, ENUM_UNKNOWN_DEFAULT_CASE_VALUE) | |||
.put(CodegenConstants.LICENSE_NAME, AbstractTypeScriptClientCodegen.LICENSE_NAME_DEFAULT_VALUE) |
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.
Just a thought: would it make at all sense to introduce an abstract options provider that has this for all current and also future typescript generators?
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.
It could make sense given that the Typescript generators seem to have a lot of options in common. I don't see any other abstract OptionsProviders though, so it is not a common practice in this repo. I could have a crack at it if I get the time, to see what it looks like.
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 implemented a shared interface which all the Typescript OptionsProviders extend, let me know if you want me to keep it in or remove it. I didn't bother to add OptionsProviders for the typescript generators which were missing ones, there might be that some of the other generators shouldn't have the parameters in the shared interface, I haven't checked that.
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 think the change is ace. @macjohnny WDYT?
...erator/src/main/java/org/openapitools/codegen/languages/AbstractTypeScriptClientCodegen.java
Show resolved
Hide resolved
@@ -11,7 +11,7 @@ | |||
"openapi-client", | |||
"openapi-generator" | |||
], | |||
"license": "Unlicense", | |||
"license": "{{licenseName}}", |
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.
lets only add it when a value is set, same in the other generators
"license": "{{licenseName}}", | |
{{#licenseName}} | |
"license": "{{licenseName}}", | |
{{/licenseName}} |
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.
The reason why I kept it like this for some and not for others is because some will always have a default value set. IDK if it is possible for this value to be unset for generators that have the default value set in the field directly.
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 guess one can explicitly set to an empty value, then it should not pass the {{#licenseName}}
condition
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 wasn't able to do this with the cli. If I set the licenseName to empty value it will still be present. I tested this on this branch with typescript-fetch
for which I have this in place already:
❯ java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate -g typescript-fetch -i modules/openapi-generator/src/test/resources/2_0/petstore.yaml -t modules/openapi-generator/src/main/resources/typescript-fetch -o samples/client/petstore/typescript-fetch/builds/default --additional-properties npmName=npmName,licenseName=
❯ grep "license" samples/client/petstore/typescript-fetch/builds/default/package.json
"license": "",
❯ java -jar ... generate ... licenseName="" > /dev/null && grep "license" ...package.json
"license": "",
❯ java -jar ... generate ... licenseName="null" > /dev/null && grep "license" ...package.json
"license": "null",
Maybe there is some other way to set it to null, but I was not able to do it.
I could still implement it, I guess it wouldn't hurt, but I don't think it's necessary.
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.
ok lets leave it as it is for now, since it has been there anyway :-D
@david-marconis thanks for your contribution! |
This change makes it possible to change the value of the license set in the package.json file for typescript client generators. Here is a detailed list of the changes made:
PR checklist
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.
master
(upcoming7.x.0
minor release - breaking changes with fallbacks),8.0.x
(breaking changes without fallbacks)@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)