This fixes the issue described in #14971, namely that when no npmName
was provided then the instructions in the generate README
fail because npm install
complains that it cannot find a package.json
.
In practice this PR provides a placeholder value for NPM_NAME
when the user did not provide one.
Consequently, a package.json
is always generated.
To test this commit I generated a typescript-angular client (from any arbitrary openapi specification file) and ran the first 2 commands mentioned in the README, ie: npm install
and npm run build
.
- With this patch: both commands ran successfully
- Without this patch: the first command fails
An alternative I considered was to generate an ad hoc README rather than always providing a package.json
. This could be achieved with a patch like this:
diff --cc modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java
index 7675df8f18c,7675df8f18c..a32bc3229cb
--- a/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java
+++ b/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java
@@@ -184,7 -184,7 +184,9 @@@ public class TypeScriptAngularClientCod
throw new IllegalArgumentException("Invalid ngVersion: " + ngVersion + ". Only Angular v9+ is supported.");
}
-- if (additionalProperties.containsKey(NPM_NAME)) {
++ boolean withNpmPackageGeneration = additionalProperties.containsKey(NPM_NAME);
++ additionalProperties.put("withNpmPackageGeneration", withNpmPackageGeneration);
++ if (withNpmPackageGeneration) {
addNpmPackageGeneration(ngVersion);
}
diff --cc modules/openapi-generator/src/main/resources/typescript-angular/README.mustache
index 3a65b9117ef,3a65b9117ef..b29e146da5b
--- a/modules/openapi-generator/src/main/resources/typescript-angular/README.mustache
+++ b/modules/openapi-generator/src/main/resources/typescript-angular/README.mustache
@@@ -1,5 -1,5 +1,6 @@@
## {{npmName}}@{{npmVersion}}
++{{#withNpmPackageGeneration}}
### Building
To install the required dependencies and to build the typescript sources run:
@@@ -11,11 -11,11 +12,13 @@@ npm run buil
### publishing
First build the package then run ```npm publish dist``` (don't forget to specify the `dist` folder!)
++{{/withNpmPackageGeneration}}
### consuming
--Navigate to the folder of your consuming project and run one of next commands.
++Navigate to the folder of your consuming project and run {{#withNpmPackageGeneration}}one of {{/withNpmPackageGeneration}}the next command{{#withNpmPackageGeneration}}s{{/withNpmPackageGeneration}}.
++{{#withNpmPackageGeneration}}
_published:_
@@@ -23,6 -23,6 +26,7 @@@ npm install {{npmName}}@{{npmVersion}}
_without publishing (not recommended):_
++{{/withNpmPackageGeneration}}
npm install PATH_TO_GENERATED_PACKAGE/dist.tgz --save
To be honest, I have very little experience in frontend (I'm more a backend dev) so I'm not sure which approach would be best. I'm proposing a PR which always generates package.json
because it seems more consistent with what the javascript client generator is doing (and also because the generated README has several references to npmName
)
Since this is related to typescript I guess I should ping @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov @davidgamero and @mkusaka
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 ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh
./bin/generate-samples.sh bin/configs/java*
. For Windows users, please run the script in Git BASH. -
In case you are adding a new generator, run the following additional script : ./bin/utils/ensure-up-to-date.sh
-
File the PR against the correct branch: master
(6.3.0) (minor release - breaking changes with fallbacks),7.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.