Not following nested refs

[openapi-ts]

Not following nested refs

[jeffpyke]

I would also be interested in this fix.

[eugenezastrogin]

npm i @manifoldco/swagger-to-ts@next fails with

npx: installed 73 in 3.025s
Cannot find module 'prettier'

I was able to get it running via cloning and building it myself and using cli.js directly though.

First thing I noticed - it no longer crashes on names like "MyData 'id' Data" in swagger.json and even properly escapes it in generated schema! I never bothered to report this issue and renamed those manually instead - glad to see it working OOTB now. :)

I take it --nowrapper option is gone? Is there a better way to export naked types then making wrapper around generated schema with:

import { definitions } from './schema.d';

export type MyShallowType1 = definitions['MyShallowType1'];
export type MyShallowType2 = definitions['MyShallowType2'];

I'm sure there should be, but I couldn't quite think of one from the top of my head. 🤔

Nested refs work great now! Great job, @DangoDev 👍🏻

[drwpow]

Thanks so much for the well-written issue and test code! I think I know where the problem lies; we had a similar problem with camelCasing. Basically, the code is “two-tiered” in a sense. The higher tier sets up the scanner based on the entry level, and differs a tiny bit in logic from the lower, recursive tier that crawls the tree. I think refs are just being handled properly in the top tier, but not the lower tier.

I should be able to patch this soon. Sorry for the delay on this.

[drwpow]

Due to some problems with the way this library handles refs, and in preparation for Swagger v3, I’m working on v2 of this library. Could you do me a favor and try the v2 branch (npm i @manifoldco/swagger-to-ts@next or npx @manifoldco/swagger-to-ts@next …)?

I believe this should fix the nested refs problem, but the generated types will be slightly different from v1 (better, IMO).

Feedback/thoughts welcome here as well on the new format (even though the PR is closed I’d gladly accept feedback you have): #178

[drwpow]

I take it --nowrapper option is gone?

Yes. Actually yeah your example works. The style was heavily-influenced by https://graphql-code-generator.com/ which I use a lot. I’ve found that for most deeply-nested paths I just assign a type to it if I need to reuse it, or just write the whole thing out if I only need it once. It’s a little awkward, but only as awkward as your Swagger schema in the first place.

Sorry I should have mentioned I wrote a draft for a migration guide in #178 that explains why and gives an example:

---

Wrappers

The --wrapper CLI flag was removed because it was awkward having to manage part of your TypeScript definition in a CLI flag. In v2, the decision was made to have you compose your wrapper in your code:

import { components as Schema1 } from './generated/schema-1.ts';
import { components as Schema2 } from './generated/schema-2.ts';

declare namespace OpenAPI3 {
  export Schema1;
  export Schema2;
}

[drwpow]

npm i @manifoldco/swagger-to-ts@next fails with

npx: installed 73 in 3.025s
Cannot find module 'prettier'

Ah good catch. That probably just got accidentally moved to devDeps. I’ll release a new version fixing that in a bit

[drwpow]

Deployed a new version @next, and I was able to run it locally. Hopefully that fixes the problem!

[RinatGumarov]

I have a problem with @next version which is currently 2.0.0-alpha.1.

> npx @manifoldco/swagger-to-ts swagger.json --nowrapper -o src/generated/swagger.d.ts

',' expected. (31:25)

Error point to this line
"ExecutorTask": [object >O<bject];
I cannot understand what the problem is, but would like to be helpful.

[drwpow]

@RinatGumarov does it work if you drop the --nowrapper option?

If not are you able to post the schema you’re using?

[drwpow]

Just released @manifoldco/[email protected] to npm, which is a library rewrite that adds OpenAPI 3.0 support and fixes issues following $refs. Please give it a try! And please open up another issue if this isn’t resolved.