Unused @ts-expect-error causes errors

[fiftyy]

Description

Hi, while i generate my client i get the following errors from the generated files:

src/api/client/client/client.gen.ts:61:3 - error TS2578: Unused '@ts-expect-error' directive.

61   // @ts-expect-error
        const { opts, url } = await beforeRequest(options);
     ~~~~~~~~~~~~~~~~~~~

Reproducible example or configuration

Config

import { defineConfig } from '@hey-api/openapi-ts';

export default defineConfig({
	input: './scripts/openapi-spec.json',
	output: { format: 'prettier', lint: 'eslint', path: './src/api/client', importFileExtension: '.js' },
	plugins: [
		'@hey-api/schemas',
		{
			name: '@hey-api/typescript',
			topType: "any",
			enums: {
				case: 'preserve',
				enabled: true,
				mode: 'typescript'
			}
		},
		{
			name: '@hey-api/sdk',
			asClass: true,
			responseStyle: 'data',
			paramsStructure: 'flat',
			classNameBuilder: (name) => `${name}Service`
		}
	]
});

OpenAPI specification (optional)

No response

System information (optional)

Node: v24.11.0

typescript: 5.9.3 @hey-api/openapi-ts: 0.87.3

[dosubot[bot]]

Hi @fiftyy! I'm Dosu and I’m helping the openapi-ts team.

The BodyInit error happens because the generated client expects DOM types (like BodyInit from the Fetch API), which aren't included by default in Node.js or non-browser TypeScript projects. To fix this, add "dom" to the "lib" array in your tsconfig.json:

{
  "compilerOptions": {
    "lib": ["esnext", "dom"]
  }
}

This will make types like BodyInit available to TypeScript and resolve the error (source).

The unused @ts-expect-error directive is likely a leftover from the code generator. If it's not suppressing any error, you can ignore it—it won't affect your build. Since client.gen.ts is generated, avoid editing it directly; if the warning is disruptive, you can adjust your linter or TypeScript settings to suppress unused directive warnings, or regenerate the client after updating your generator version (source).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fiftyy]

The BodyInit error happens because the generated client expects DOM types (like BodyInit from the Fetch API), which aren't included by default in Node.js or non-browser TypeScript projects. To fix this, add "dom" to the "lib" array in your tsconfig.json:

{ "compilerOptions": { "lib": ["esnext", "dom"] } } This will make types like BodyInit available to TypeScript and resolve the error (source).

This fixes the BodyInit issue. Thank you AI :) Hope thats the right solution...

But the error with the ts directive is always there.

[fiftyy]

The BodyInit error happens because the generated client expects DOM types (like BodyInit from the Fetch API), which aren't included by default in Node.js or non-browser TypeScript projects. To fix this, add "dom" to the "lib" array in your tsconfig.json: { "compilerOptions": { "lib": ["esnext", "dom"] } } This will make types like BodyInit available to TypeScript and resolve the error (source).

This fixes the BodyInit issue. Thank you AI :) Hope thats the right solution...

But the error with the ts directive is always there.

@dosu

[dosubot[bot]]

Glad the BodyInit issue is fixed! The unused @ts-expect-error warning happens because the generator adds this directive as a precaution, but if TypeScript doesn't see an error on the next line, it flags the directive as unused. The official docs don't mention this warning or provide a config to suppress it. Since client.gen.ts is generated, it's best not to edit it directly. You can safely ignore the warning, or if it's disruptive, configure your linter or TypeScript to suppress unused directive warnings for generated files. Keep an eye on generator updates in case this gets addressed in future releases.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fiftyy]

Glad the BodyInit issue is fixed! The unused @ts-expect-error warning happens because the generator adds this directive as a precaution, but if TypeScript doesn't see an error on the next line, it flags the directive as unused. The official docs don't mention this warning or provide a config to suppress it. Since client.gen.ts is generated, it's best not to edit it directly. You can safely ignore the warning, or if it's disruptive, configure your linter or TypeScript to suppress unused directive warnings for generated files. Keep an eye on generator updates in case this gets addressed in future releases.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

@dosu I cant ignore the warning because it wouldnt start my application. I mean this is a unneccseary used ts-directive. So why not remove them from code gen.

[dosubot[bot]]

You're right—there's currently no documented way to prevent or configure the emission of unnecessary @ts-expect-error directives in the generated code from @hey-api/openapi-ts, and the docs don't mention this issue or provide a workaround. This is a known pain point for strict TypeScript setups, especially when the directive is left in without an actual error, as it can break builds that treat unused directives as errors.

Since editing generated files isn't practical, the best options for now are to monitor for updates to the generator that might address this, or (as a last resort) use a post-processing script to strip out unused @ts-expect-error lines after generation—though that's not ideal for maintainability. If this is blocking your workflow, highlighting it in the project's issue tracker can help prioritize a fix in future releases.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[jrjurman-jellyfish]

I'm also running into this. I ended up excluding the generated api files in my webpack typescript loader, and that appears to have solved the problem (or, at least, allowed the build tooling to continue).

[hansmbakker]

This is likely a duplicate of #2531- can you please upvote that issue?