-
-
Notifications
You must be signed in to change notification settings - Fork 243
fix(nuxt): skip generation during prepare if no input & config types #2618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@RihanArfan is attempting to deploy a commit to the Hey API Team on Vercel. A member of the Team first needs to authorize it. |
|
1497aaf
to
5791605
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this will fix the occasional crash I've been running into so THANK YOU for that. I just need some context around the other changes made so I can clean up the docs to match the style elsewhere
--- | ||
title: Nuxt v3 Client | ||
description: Generate a type-safe Nuxt v3 client from OpenAPI with the Nuxt client for openapi-ts. Fully compatible with validators, transformers, and all core features. | ||
title: Nuxt Client |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why make these changes? Once we finalize this page, we should have a v4 page too, it's ambiguous which version it's compatible with otherwise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going forwards a major Nuxt release should still be backwards compatible with older modules. When Nuxt v5 releases Q4 25/Q1 26 the same module should work without any new changes. Since Nuxt 2 is EOL I don't think there'll be any confusion about using the module with it.
https://nuxt.com/docs/4.x/guide/going-further/modules#do-not-advertise-with-a-specific-nuxt-version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! I will still want to polish some of the wording in this copy, but overall I agree with the changes you've made/are making
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you 😄 docs isn't my strong suit
plugins: [ | ||
{ | ||
name: '@hey-api/client-nuxt', | ||
runtimeConfigPath: './shared/lib/hey-api.ts', // [!code ++] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you sometimes use the ./shared/lib
path in your examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The runtime config path should be within ./app
or ./shared
because of how Nuxt generates the tsconfigs for it's imports etc. so #hey-api/
will resolve to the generated client. If the file was directly in the project root, TS would throw errors since it can't resolve the import.
Originally I thought the generated Nuxt client could be used in both the frontend and server routes, so I figured the shared directory would be the best Nuxt folder for it. I just tested now and the generated client can't be used within server routes.
So based on this the Hey API docs should be recommending people put that file within ./app
(anywhere). I guess the runtime config could reside in utils, but given that's an auto imported directory I think users using lib
is better.
runtimeConfigPath: './shared/lib/hey-api.ts', // [!code ++] | |
runtimeConfigPath: './app/lib/hey-api.ts', // [!code ++] |
We only need to mention it within the docs in the runtime config section, and it doesn't need to be added to other examples imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would need to change to make it work within server routes? Seems like an important issue, even if not directly related to this pull request
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it would make it so convenient for both building fully fullstack Nuxt, or BFFs (which are really popular with Nuxt).
I believe the issue is because the client has imports for Nuxt and Vue things which can't be used on Nitro server routes.
openapi-ts/packages/openapi-ts/src/plugins/@hey-api/client-nuxt/bundle/client.ts
Lines 1 to 7 in 91bc2d0
import { | |
useAsyncData, | |
useFetch, | |
useLazyAsyncData, | |
useLazyFetch, | |
} from 'nuxt/app'; | |
import { reactive, ref, watch } from 'vue'; |
What I'd suggest is creating @hey-api/client-nitro
@hey-api/client-ofetch
(which basically a super simplified Nuxt client copy) and the Nuxt module can register these server imports with addServerImports()
. As a standalone ofetch client, people using that outside of Nuxt/Nitro also benefit similar to how there's an Axios one.
On top of this you could create a separate Nitro module for standalone Nitro users (since it's a fantastic backend framework) which acts similarly to the Nuxt module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I think the CI error you're seeing is what I refer to in my message above haha
Thanks for reviewing it so fast ❤️ I've responded to your questions. Lmk if there's anything else you'd like to know. ~~With the Nuxt module specifically, there is a postinstall script which does need the I'm going to edit the CI workflow to sort it out now~~ Update: just edited the package.json to move the postinstall/nuxt prepare script to be ran before build instead. If there's a contributing guide or any docs for developing: to work on the nuxt module after cloning this repo, first run |
skipping as @hey-api/openapi-ts throws an exception if missing input which makes prepare fail
5791605
to
19fa633
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are still some CI fails, but the good news is, the error is different now 🎉
"scripts": { | ||
"build": "nuxt-module-build build", | ||
"dev": "tsup --watch", | ||
"dev:prepare": "nuxt-module-build prepare", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how does development work now? Do you just run this script instead of dev? If so, why not keep it named dev?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now there's no way for previewing local development outside of TS type checking, since there's no playground. I can add back a playground so local development, manual testing and an example of usage is available.
Normally this is how local development looks:
- git clone
- pnpm i
- pnpm dev:prepare # generates types and stubs for local dev
- pnpm dev # launch the nuxt app inside playground/ which uses the module with hot reloading.
- https://github.com/nuxt/starter/blob/module/package.json#L27-L29
The dev:prepare script currently just generates the .nuxt directory (which contains things like the generated tsconfig etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to burden you with the playground, if the CI checks pass that should be enough for now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RihanArfan are you able to fix the typecheck issue?
Some bug fixes and improvements to the Nuxt module and documentation.