feat: generate types from OpenAPI schemas

[mattmess1221]

🔗 Linked Issue

#32

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSDoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Types can now be generated for an API if it defines an OpenAPI schema. By specifying the schema on the endpoint as a url, file, schema object, or function returning the schema object, types for the paths and components will be generated in .nuxt/types/nuxt-api-party-types.d.ts.

Types can be imported directly via

import { components, paths } from '#nuxt-api-party/myApi'

Resolves #32

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[netlify]

✅ Deploy Preview for nuxt-api-party ready!

Name	Link
🔨 Latest commit	b2f1e55
🔍 Latest deploy log	https://app.netlify.com/sites/nuxt-api-party/deploys/64df17175768c0000884b8c5
😎 Deploy Preview	https://deploy-preview-33--nuxt-api-party.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[johannschopplich]

Dang, that was fast. 👏 Will take me some time to review. But thanks in advance!

[johannschopplich]

Quick question: What do you mean by {}?

We shouldn't use {} as a type. {} actually means "any non-nullish value", according to ESLint.

• If you want a type meaning "any object", you probably want object instead.
• If you want a type meaning "any value", you probably want unknown instead.
• If you want a type meaning "empty object", you probably want Record<string, never> instead.
  ...

See the eslint@typescript-eslint/ban-types.

[johannschopplich]

Hey @killjoy1221 I just reviewed most of your code. Looks quite promising. I have refactored some code, to bring it closer to Nuxt standards. For example, instead of relying on require.resolve, we can use a Nuxt kit util:

const hasOpenAPIPkg = await tryResolveModule('openapi-typescript', [nuxt.options.rootDir])

But in the end, minor optimizations. I haven't touched your logic a lot. The OpenAPI stuff is complicated and I might get 75 % of it. Looking good tho. I have one question left – see review tab. Then, I will have to take a look at why the tests are failing.
Looks like we can release soon. Thanks a lot for your efforts!

[mattmess1221]

No problem. I always expect a bit of nitpicking when it comes to coding standards.

I agree that the OpenAPI types are complex. I tried to support path parameters via template strings `pet/${petId}`, but I could never get the type to resolve properly. Maybe I'll get it later and create a new PR.

[johannschopplich]

Yeah, maybe TS can't infer the type from a concatenated string. There is the Split utility from type-fest, which might help?

Anyway, thanks for your contribution. It's a hell of a lot of work! I will release a new package version later today. Glad you helped. :)

[johannschopplich]

@killjoy1221 Nuxt API Party v0.14 just released! 🏁