0.9.4 breaks some Typescript configurations

[djMax]

Description

Something in the changes in 0.9.4 causes NodeNext module resolution to fail.

#1634

Reproduction

Node.js side, but build time so no reason browser wouldn't also be affected. I can't get the playground to fail because I don't have full control of tsconfig it seems, but here's what fails in a local build with specific tsconfig values (as described in the discussion):

Playground

Expected result

URLs should be "known" but end up just being ignored/allow any value.

Checklist

• I’m willing to open a PR (see CONTRIBUTING.md)

[drwpow]

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.

[djMax]

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.

[djMax]

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 :)

[jacquesg]

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.

[drwpow]

Investigated this a little further and in planning for the upcoming 0.10.0 release (which requires openapi-typescript@7.x 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 openapi-typescript@6.x 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.

[drwpow]

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?

[noetix]

Not resolved here.

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

[Baldinof]

It seems to be resolved with openapi-fetch@0.11.1 and openapi-typescript@7.3.0. Thanks :)

[drwpow]

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.

[osmestad]

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.

[mikavilpas]

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