next-rest-framework
next-rest-framework copied to clipboard
Generated openapi.json appends /route.cjs to every Next JS App Router API endpoint
As above, everything's working fine but all my Next JS (App Router) API endpoints have /route.cjs appended to them in the generated openapi output when I run the CLI generate operation.
Is this intentional and is there any way to override this behaviour as it's unnecessary noise in my API docs?
e.g. my API endpoint: "/api/test" is being output as "/api/test/route.cjs"
Thanks
No, this is not intentional, thanks for reporting. Do you have a reproducible example and what versions of Node.js, Next.js and this framework are you experiencing this with and on which OS?
Node 18.18.2, Next JS 14.1.3 and framework 5.1.11 on Windows 11 - I can put together a standalone example if needed.
Also, is it possible to use the cli generate command with a standalone openApiObject/config file or is a GET docsRoute api handler always necessary for this, even if rendering a redoc/swagger UI isn't required? If not, this would be a great option, as I'm sure many will want to leverage the framework purely for openapi generation for use in other tools/platforms.
Node 18.18.2, Next JS 14.1.3 and framework 5.1.11 on Windows 11 - I can put together a standalone example if needed.
Also, is it possible to use the cli generate command with a standalone openApiObject/config file or is a GET docsRoute api handler always necessary for this, even if rendering a redoc/swagger UI isn't required? If not, this would be a great option, as I'm sure many will want to leverage the framework purely for openapi generation for use in other tools/platforms.
Currently the docs endpoint is required for the CLI to find the config, but I agree that we could decouple this for cases when a developer does not want to expose a publicly rendered documentation but they want to generate the openapi.json
e.g. for internal purposes. In this case the configuration could be defined in a separate JSON/TS file and the generated openapi.json
file should not be generated in the public folder but e.g. in the root of the project or a user-defined path.
About the original problem in this issue, I haven't had the time to configure a Windows environment to reproduce this yet but I will try to tackle it ASAP.