search

blomqma / next-rest-framework

Type-safe, self-documenting APIs for Next.js
https://next-rest-framework.vercel.app
Other
134 stars 17 forks source link

Generated openapi.json appends /route.cjs to every Next JS App Router API endpoint #145

Open jameslshannon opened 5 months ago

jameslshannon commented 5 months ago

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

blomqma commented 5 months ago

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?

jameslshannon commented 5 months ago

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.

blomqma commented 5 months ago

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.