Issue importing createClientConfig
Description
I recently upgraded from version 0.82.5 to 0.83.1 and after regenerating my client with the new version an import path changed, resulting in an error.
Was I supposed to update some configurations maybe specifying the file path?
Line with error: https://github.com/daniel-mizsak/linker/compare/main...feature/update-openapi-ts#diff-20dfcf317bf54398701a5cd3ee4af180ceda8ac0553828465bd7bf3e978ac437R10
Error:
Import trace for requested module:
./src/client/sdk.gen.ts
./src/client/index.ts
./src/components/linker/CreateLink.tsx
⨯ ./src/client/client.gen.ts:10:1
Module not found: Can't resolve './src/hey-api.ts'
8 | createConfig,
9 | } from "./client"
> 10 | import { createClientConfig } from "./src/hey-api.ts"
| ^
11 |
12 | /**
13 | * The `createClientConfig()` function will be called on client initialization
https://nextjs.org/docs/messages/module-not-found
Re-generating the client code with the previous version fixes the issue.
Reproducible example or configuration
https://github.com/daniel-mizsak/linker/compare/main...feature/update-openapi-ts
OpenAPI specification (optional)
No response
System information (optional)
No response
Hi @daniel-mizsak! I'm Dosu and I’m helping the openapi-ts team.
The error means the generated client expects a file at ./src/hey-api.ts that exports createClientConfig, but that file doesn't exist or isn't in the right place. With recent versions, if you set runtimeConfigPath in your codegen config (for example, runtimeConfigPath: './src/hey-api.ts'), you need to manually create that file and export a createClientConfig function from it. Here’s a minimal example:
// ./src/hey-api.ts
import type { CreateClientConfig } from './client/client.gen';
export const createClientConfig: CreateClientConfig = (config) => ({
...config,
// Optionally override config values here
});
Make sure the path matches what’s set in your codegen config and that the file exists after codegen runs. If you don’t want to use a custom config, remove the runtimeConfigPath option from your config and re-generate the client. More details and examples are in the docs: Next.js client config.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Most likely caused by https://github.com/hey-api/openapi-ts/blob/91bc2d0074fdd9e1c3bf909a8cc96b8940155191/packages/codegen-core/src/files/file.ts#L218-L229
@mrlubos I have a similiar issue with the runtimeConfigPath as ./src/hey-api.ts
With 0.82.5 it generated the correct import as;
import { createClientConfig } from '../../../hey-api';
The recent release 0.83.1 generates as;
import { createClientConfig } from './src/hey-api.ts';
Which results in an error;
openapi-ts.config.tsis at the root of the projectcreateClientConfigfile is atsrc/hey-api.tsruntimeConfigPathfor@hey-api/client-nextis./src/hey-api.tsoutput.pathissrc/services/api/openapi
I’d suggest resolving the path with process.cwd() and dropping the .ts extension in the import. This avoids the generated path being tied to the output file’s location and keeps imports stable.
+ import path from "node:path";
{
- runtimeConfigPath: "./src/client.ts"
+ runtimeConfigPath: path.resolve(process.cwd(), "./src/client.ts")
}
That yields a safer relative import:
- import { createClientConfig } from "./src/client.ts";
+ import { createClientConfig } from "../client";
If you’re running on Bun, you can also use Bun.resolveSync for the same effect:
runtimeConfigPath: Bun.resolveSync(
"./src/client.ts",
process.cwd(),
);
Hi, I also have this issue, i've tried your workaround, but it does not work well (at least on windows).
The path I get in client.gen.ts is prefixed by a dot
import { createClientConfig } from './C:/Users/[...]/src/lib/api-config.ts';
Forget my above comment, when I use your workaround and bump to version 0.87.1 the path is correct. Thanks
@nghiepdev answer helped me. For nodejs use path
import path from "path";
runtimeConfigPath: path.resolve("./src/bootstrap/api.ts"),
What is your recommendation @mrlubos, it is better to update and use some workaround, or wait for the fix?
@daniel-mizsak if the above fix works in the meantime, that's an easy one-liner. I plan to fix it though which is why I keep the issue open!