We’re not planning on allowing non-Mustache templates shipped with oag until we have significant improvments on architecture. Namely, we’ve discussed a testable object instance/interface which is passed to templates rather than a
Map<String, Object>with an undefined structure. We’re also looking to separate template logic from generation logic so we don’t need to have a method in a base type that requires knowledge of the template engine in order to monkey patch it’s compiler.
Thanks for the update. Are these changes being planned for 5.0?
the front-end was Angular
and back-end was JS
I'm working now on generating a NodeJS codebase for OpenAPI 3
@YishTish yeah that’s pretty much my exact use case - js backend and vue.js front. Trying to work out how I can use the OpenAPI spec to create boilerplate for front and backend, as well as supporting any testing. Was hoping there may be some nice blog post series on it. Don’t have the bandwidth to work it out from scratch.
@GazEdge - I don't know which output languages are available. Once you have the openapi-generator working on your computer (there are many ways to get it working, PM me if you need a walkthrough of that), you can type openapi-generator and get a list of available outputs. Then, run openapi-generator generate -i {{path to your openapi.yaml/json file}} -l {{language you want to generate, based on the list retrieved earlier}} -o {{directory where the generated code should be written}}. If all goes well, you should have all you need to start your project. Go through the files that were generated and get a feel of your environment. It should be pretty self-explanatory.
I'm working on a nodejs-express generator. Still work in progress. If you want to see what I've done so far, please let me know.
I'm working on a nodejs-express generator. Still work in progress. If you want to see what I've done so far, please let me know.
[main] INFO o.o.codegen.DefaultGenerator - OpenAPI Generator: openapi-yaml (documentation)
[main] INFO o.o.codegen.DefaultGenerator - Generator 'openapi-yaml' is considered stable.
{
"openapi" : "3.0.0",
"info" : {
"title" : "My Microservice API",
"description" : "......",
"termsOfService" : "http://sam.adidas.com/ts",
"license" : {
"name" : "Proprietary",
},
"version" : "1.2.0"
},
"servers" : [ {....
} ],
"paths" : {
"/users" : {
"x-summary" : "Users Collection",
"x-description" : "Retrieve user infomation"
"get" : {
"tags" : [ "users" ],
"summary" : "find",
"description" : ...",
"operationId" : "findUsers",
"parameters" : [ {...} ],
"responses" : {....},
}
Is it even accessible ?
@GazEdge if you want great mock-servers you should use the haskell-backend... :)
We have some mocking laying around here - and it even gets easier with
I think i have to write a blogpost or so about that .. :/
We have some mocking laying around here - and it even gets easier with
deriving via .. so in about 5min-1h you can have a full generated json-mock-server up & running.. even with domain-specific data..I think i have to write a blogpost or so about that .. :/
@Fjolnir-Dvorak did some work on that with me .. ;)
@wing328 Woudl it make sense to add vendorExtension also to that level ?
we do this already if you define a parameter in "path".
Then you have them in each of the operation defined under this path.
@wing328 @jimschubert Is there a good-practice workflow when using openapi generation with javascript? For example, when using it in Java spring, the open api generator maven plugin makes it very easy. One just has to run maven compile and all of your generated files are updated according to your openapi.yaml file. Is there anything like that for javascript or will one have to run the update process manually each time for openapi.yaml file update?
@parrotcar00 if you're using node, you can use the npm module: https://github.com/OpenAPITools/openapi-generator-cli. This is just a wrapper around the Java artifact, but you can create automation in your project pretty easily
@parrotcar00 you may also publish the auto-generated JS SDK Github repo, e.g. https://github.com/wing328/petstore-js.
@cbornet hey, if you have some time to spare, could you please take a look again at OpenAPITools/openapi-generator#3474 ? a simple thumbsup/thumbsdown to let me know if I should start doing the modifications on the other library templates and regenerating samples
hmm, I am wondering. The project has a checkstyle file. Is that file to be used? At the moment it is broken (LeftCurly has no child property " <property name="maxLineLength" value="100"/>". After I repaired that locally I ran checkstyle and the result was horrific...
The file DefaultCodegen.java has 352 style violations on its own...
The file DefaultCodegen.java has 352 style violations on its own...
makes me wondering. Should the eclipse formatter config file be used or is that one historic, too?
And another question. Did anyone tried to delete the samples folder and to regenerate it? After fixing the typescript-fetch scripts which are copying files without creating the directories and ignoring meta-codegen.sh (something there is broken, too, if I am trying to regenerate all sample after executing "rm -rf samples") I got about 9920 deleted files which are no longer generated anymore...
It could also be that I understand the whole project totally wrong though. But how else shall I regenerate the golden files if I made a change which would result in a file rename which I will do with the fix of case sensitive reserved word escaping
It could also be that I understand the whole project totally wrong though. But how else shall I regenerate the golden files if I made a change which would result in a file rename which I will do with the fix of case sensitive reserved word escaping
Things under
samples include unit tests and pom.xml files which allow us to compile and execute some supported outputs as part of our CI. You can't just delete and recreate the directory. ~10k files sounds like a node_modules directory, maybe? I'd suggest deleting only the files you expect to no longer be generated within the generator you're modifying.
I did not check yet if the file ensure-up-to-date.sh does what it should do
all other languages did copy their test pom.xml files from CI/samples into samples, so that worked just fine
Is it correct that OCaml is not tested by ensure-up-to-date.sh?
If what I did was wrong it is easy to fix for me since I separated those changes in different branches / commits. I assume a rebase is possible on a pull request
Would it be possible to distinguish generated from manual supplied but still needed files? At the moment the files are generated in the same folder where files are lying which were added manually. That does make a well tested change nearly impossible since there is no way to distinguish those files
@cbornet hey, so I added the example to https://github.com/OpenAPITools/openapi-generator/pull/3474#issuecomment-516772779 - feel free to take a look and comment
@wing328