Skip to content

Conversation

RihanArfan
Copy link

@RihanArfan RihanArfan commented Sep 9, 2025

Some bug fixes and improvements to the Nuxt module and documentation.

Copy link

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

Copy link

vercel bot commented Sep 9, 2025

@RihanArfan is attempting to deploy a commit to the Hey API Team on Vercel.

A member of the Team first needs to authorize it.

Copy link

changeset-bot bot commented Sep 9, 2025

⚠️ No Changeset found

Latest commit: 2f01555

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. bug 🔥 Something isn't working client Client package related docs 📃 Improvements or additions to documentation labels Sep 9, 2025
@RihanArfan RihanArfan changed the title fix: skip generation during prepare if no input fix(nuxt): skip generation during prepare if no input Sep 10, 2025
Copy link
Member

@mrlubos mrlubos left a 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
Copy link
Member

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

Copy link
Author

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

Copy link
Member

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

Copy link
Author

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 ++]
Copy link
Member

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?

Copy link
Author

@RihanArfan RihanArfan Sep 10, 2025

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.
image

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.

Suggested change
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.

Copy link
Member

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

Copy link
Author

@RihanArfan RihanArfan Sep 10, 2025

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.

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

Copy link
Member

@mrlubos mrlubos left a 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

@RihanArfan
Copy link
Author

RihanArfan commented Sep 10, 2025

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 openapi-ts to be built. Cannot find module '/home/runner/.../node_modules/@hey-api/openapi-ts/dist/index.cjs' (dist)

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 pnpm run dev:prepare

Copy link
Member

@mrlubos mrlubos left a 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",
Copy link
Member

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?

Copy link
Author

@RihanArfan RihanArfan Sep 11, 2025

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:

The dev:prepare script currently just generates the .nuxt directory (which contains things like the generated tsconfig etc).

Copy link
Member

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!

Copy link
Author

@RihanArfan RihanArfan Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the CI failures are related to type checking the pinia colada examples

image image

I've pushed a fix for the other issue which has triggered CI and hopefully the other one works 🤞

@RihanArfan RihanArfan changed the title fix(nuxt): skip generation during prepare if no input fix(nuxt): skip generation during prepare if no input & config types Sep 11, 2025
Copy link
Member

@mrlubos mrlubos left a 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🔥 Something isn't working client Client package related docs 📃 Improvements or additions to documentation size:L This PR changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants