Unable to generate

[DHoper]

It's my first time use this package I'm using next app router，and I setting up endpoint file as the docs say like:

// src/app/api/v2/route.ts

import { docsRoute } from 'next-rest-framework';

// export const runtime = 'edge'; // Edge runtime is supported.

export const { GET } = docsRoute({
  // deniedPaths: [...] // Ignore endpoints from the generated OpenAPI spec.
  // allowedPaths: [...], // Explicitly set which endpoints to include in the generated OpenAPI spec.
  // Override and customize the generated OpenAPI spec.
  openApiObject: {
    info: {
      title: 'My API',
      version: '1.0.0',
      description: 'My API description.'
    }
    // ...
  },
  // openApiJsonPath: '/openapi.json', // Customize the path where the OpenAPI spec will be generated.
  // Customize the rendered documentation.
  docsConfig: {
    provider: 'redoc', // redoc | swagger-ui
    title: 'My API',
    description: 'My API description.'
    // ...
  }
});

but I get :

I've view the others closed issues，and then I update my node.js from 18 to 20 version but the problem is still the same

[blomqma]

Which version of next-rest-framework are you using? Would you mind trying again with v6.0.0 and check if the problem is still present?

[dror-trail]

reproduced with "next-rest-framework": "^6.0.1",

[mirko314]

I've just ran into this as well. The CLI does not output an error when one forgets to add the TSX import inside the CLI like in this example: NODE_OPTIONS='--import=tsx' npx next-rest-framework generate findAppRouterConfig should forward this error that is thrown if tsx is not imported:

error TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for 
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:160:9)
    at defaultGetFormat (node:internal/modules/esm/get_format:203:36)
    at defaultLoad (node:internal/modules/esm/load:143:22)
    at async ModuleLoader.load (node:internal/modules/esm/loader:409:7)
    at async ModuleLoader.moduleProvider (node:internal/modules/esm/loader:291:45)
    at async link (node:internal/modules/esm/module_job:76:21) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}```

[Jayllyz]

Same issue, Next 14.2.3 (app router) with the latest version of next-rest-framework 6.0.1.

Any solutions?

[revskill10]

Any issue ? 6.0.0 also failed with same error.

[MilanDeruelle]

Any updates on this? Did anybody figure it out?

I just setup a basic project with next-rest-framework and I can't get it to run...

EDIT: After doing some debugging I believe the issue arises from the dynamic import in the findAppRouterConfig function. const res = await import(url).then((mod) => mod.default); leads to res=undefined. If I just run await import(url).then((mod) => console.log(mod))in the debugger, I do get something (I believe the expected) module.

EDIT2: Can confirm that replacing await import(url).then((mod) => mod.default); with await import(url); in the dist files fixes the issue.

Maybe something to do with using es6 vs older syntax?

[ergodic1]

I spent a day trying to get it working as well. Next rest framework relies on being able to introspect your typescript project, and depending on your setup (ours is complex), this will just fail as you have found. In my case no matter what we tried we couldn't get it to run.

We moved to https://clover.sarim.garden/ which instead forces you to declare your api routes rather than introspecting them, and in hindsight I think that's nice as it gives us control.

[ghislaine-laios]

When introspecting next-rest-framework is trying to import ts files from another nextjs project, which could be really hard to be done right without triggering errors.

A nextjs project is not a plain nodejs project: it is designed to be used with bundler to bundle the source files first then serve from the .next directory, neither than just use some loader (like ts-node) to load the source file directly, so trying to import a ts file which could contain path aliasing and other features supported by the bundling mechanism in next-rest-framework would always fail, even with some magic NODE_OPTIONS added like "--import=tsx" or "--loader=ts-node/esm".

The actual source files the next-rest-framework is about to import are the transformed files residing in the .next dir instead of the complex ts or tsx files in the src/app directory. But even this approch has its downside: In a developing serve (i.e. next serve) only the routes actually visited will be generated under the .next folder, so next-rest-framework will never have the opportunity to get what it want before the target route is already visited. After all, import actually any code from another completely different application level project is not easy and not ergonomic.

The idea of introspecting is great, but it requires a lot of effort. One way to solve this problems is to learn prisma ORM: using some restricted config file format and generating some interesting objecst from it, and after that the user (nextjs application maker) use those stuff to implement a server. Such that we split a total mess into API spec and implementation, giving us a chance to figure out the OpenAPI information simply by parsing that config file. This approach requires significant design and trade-offs to make the entire development process ergonomic; the OpenAPI specification is still difficult to write directly.

Another way to solve the problem could be using a Webpack plugin. By integrating it into the Webpack pipeline used by Next.js, we can emit the OpenAPI spec file during the build process, similar to how .d.ts files are emitted in some projects.