I have created apis endpoint with Swaggerhub and successfully exported to run with asp.net core. I want to test the same apis with nestjs but i found documenting with openapi but not the other way round; convert yaml to nodejs.Is there a way to generate to nestjs with typescript from OpenAPI3.0 schema?
Swagger Codegen does not offer Nestjs generator at the moment. Here is a related request but no one seems to have found the time to make the contribution yet: https://github.com/swagger-api/swagger-codegen/issues/9559
UPDATE: there's PR to add a Nestjs generator in OpenAPI Generator (a community fork of Swagger Codegen)
I believe Swagger-js-codegen can help you achieve this.
Now there seems to be one project, as far as I can see, that can generate Nest.js code from a Swagger / OpenAPI spec file:
It's called swagger-nestjs-codegen. See here on Github and here on npmjs.com. I have yet to test it, though.
Related
I work into a existing nodeJS project and I would like to use swagger codegen to automate the documentation.
Currently I write the swagger doc after to have code and there is always a time lag between dev and production....
I find two solutions. The first generate the node js projet and after you code inside, but my project have one year and lot of code...
The second solution is to write a syntax in my code and automate the documentation after with command line but this solution don't use yaml and my actual doc is to write is Yaml...
Thanks :)
If your existing node.js project uses Express as its web framework, you could consider using swagger-spec-express which would enable you to simply annotate your existing express api with swagger info.
I want to use Swagger/OpenAPI to standardize documentation efforts. Most of the API's are built with NodeJS and I do integration testing with Mocha & Chai which helps tremendously with quickly making sure the API isn't broken after making changes. From what I understand, using Swagger won't replace my integration test but will make it easy for developers to know how to consume my API. If I can tie my documentation efforts into my test suite, it would make on-going documentation maintenance easier. When i add or modify test, I could update API documents in the same place.
What I was thinking about doing is using YUIDoc or JSDoc which generates API documentation from comments in source. But neither conform to OpenAPI spec. Then I found Swagger-JSdoc and figured I could just put all the comments in my test suite code since I'm already there specifying what to test in the endpoints.
Is there another way/workflow that might be more efficient for new or existing projects? How can I bring my documentation efforts closer to my test suite to improve on-going documentation maintenance?
I just published an npm module for the same. Not sure if you found an alternative, if not please feel free to give it a try.
https://github.com/LmntrX/mocha-swagger/
Install mocha-swagger globally with
npm install -g mocha-swagger
Then execute the following command:
mocha-swagger path/to/project/tests
This command will recursively parse test files in your test directory and generate a basic swagger.json file in current directory.
NB: Please note that the swagger spec generated will only contain your routes, methods and path parameters.
I am using swagger js codegen to generate source code in nodejs .it works superb.
However i have question ,
If we use swagger codegen and use java lang , models and handlers gets generated as part of stubs generation but in swagger js codegen it does not generate any models.
can you please guide me if we can generate models in swagger js codegen .This will actually help when there is an change in api it will automatically generate the models without we manually changing.
Kindly suggest if any other approach is available for nodejs.
Is this answer what you need?
quoting, "As opposed to previous versions of swagger-node (fka swagger-node-express), the swagger definition is used as the source of truth. There is no model file generated for each model in the application. So the -Dmodels will have no effect.
You can generate the response payload and send it back, and even configure the framework to validate that it follows the definition."
I am trying to mock the REST API using swagger.. I currently created nodejs project in which the default js appreas which is hello_world.js in ./api/controllers/hello_world.js.
Now I want to create a new controller and want to refer that to my YAML, that is from swaggerUI.. How can I do it? Any link would be much useful.
I am only mocking APIS, not developing.
Many thanks in advance.
Checkout the swagger codegen project, which generates server stubs based on the api specification. Node.js is among the supported languages: https://github.com/swagger-api/swagger-codegen
I have an application developed with Node.js/expressjs. It's working fine. Now I need to generate API document using Swagger. There is a module swagger-node. Do I need to re-write the whole app using this module or is there any other solution to use this module and what is the use of swagger-ui if using swagger-node.
Not from what I can tell. You should be able to generate your swagger project as described, and then just make sure that the information in the yaml file points to the actual controllers and methods that your code uses.
You can create a standalone yaml file that is compliant with Swagger/OpenAPI which can therefore be rendered into Swagger documentation. The Swagger-UI is useful for creating this yaml file. Swagger also offers various tools for testing APIs and generating code -- to use these effectively you will need a method for integrating the controller/model definitions in your yaml file into your existing codebase.
To achieve this integration I typically expose my existing codebase as an api of controller functions -- then import it as a module into the code generated by my documented API. This allows me to trust my API documentation without the burden of porting my whole codebase into Swagger's required directory structure. I believe this is the best currently available approach but is not always worthwhile.