0.9.4 breaks some Typescript configurations about openapi-typescript HOT 12 OPEN

Running into exactly the same problem, currently stuck on 0.9.3, all versions afterwards lose all type information.

Whereas it used to work :)

Tried both openapi-typescript-helpers 0.0.7 and 0.0.8, no difference in the generated output together with openapi-typescript 6.7.6

My tsconfig.json has both module and moduleResolution set to NodeNext.

from openapi-typescript.

It seems to be resolved with [email protected] and [email protected]. Thanks :)

from openapi-typescript.

Thanks @Baldinof. Issue is still open because we didn’t find the original root cause as to what went wrong. But when it comes to advanced TypeScript inference, combining lots of objects that can differ from one user to the next, it’s easy to create “impossible unions” of types. openapi-typescript@7 was the first version released since openapi-fetch came out, and it generates a lot of key?: never types which at first glance seem like wasted boilerplate, but actually help make inference more efficient and more accurate (TS likes when all the shapes are the same).

I suspect the original issue had to do with the perfect storm of limitations of openapi-typescript@6 coupled with openapi-fetch working around those limitations as best it could, and some user-generated schemas not being in our test suite. Whether or not we could have solved it on the previous versions is hard to say. But either way, will leave this issue open for longer to see if others report problems with the current versions.

from openapi-typescript.

Thanks for the investigation! Looking into it. It could have something to do with a change to openapi-typescript-helpers. I think I’m going to add tests for different moduleResolutions somehow. Could or could not be the problem based on #1634, but couldn’t hurt to eliminate that as a possibility. This seems like a bug, as TSConfig settings shouldn’t affect type safety.

from openapi-typescript.

Let me know if I can help - I had a sniff that the helpers might be involved too but I couldn't quite see how. There are a number of typing related changes in there, so it's a bit beyond my limited current understanding of the type infra here.

from openapi-typescript.

Is this theoretically fixed? I think it is but I have only seen that the playground errors now (as it should). But before I go through the variety of deps to update would love to know it was intentional :)

from openapi-typescript.

Investigated this a little further and in planning for the upcoming 0.10.0 release (which requires [email protected] which will also get a stable release at the same time) this is hopefully fixed. Or if not fixed, easier to debug.

I believe some of this came from [email protected] generating a lot of partial schemas, which made inference harder. 7.x generating full schemas with never types means openapi-fetch can get simpler inference, and easier cross-comparison since all shapes are fully outlined. Or that’s the hope, at least.

from openapi-typescript.

Some of the type inference that I believe led to the regression has been changed in 0.10.0. Are people still seeing the failures with the latest version?

from openapi-typescript.

Not resolved here.

Bumped both fetch and generator to latest, regenerated, but no types. Using nodenext.

from openapi-typescript.

I think I'm still having this problem :-( (with latest versions: "openapi-fetch": "0.12.0", "typescript": "5.6.2")

For a Node project, the only way I get types is with "module": "CommonJS", in tsconfig, setting "module": "NodeNext", breaks it.

from openapi-typescript.

Is any reproduction available? I have a project at work that

• uses ESNext modules (esm = transpiles into import/export syntax)
• tsconfig moduleResolution set to "Bundler"
• package.json has type: "module" to indicate that esm should be used (I guess)

The module system in javascript is a bit complicated to say the least (there's some light reading available at https://www.typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format).

edit: forgot to say that in the case of my project, I don't get this issue

from openapi-typescript.

I think I figured out my problem, if I switch the TS "module" type I also need to add file extensions to the imports of the files (for modern/ESM format) it seems. So I guess that makes sense :-)

from openapi-typescript.