Vite plugin docs & thoughts

[Matsuuu]

Description

Heya,

As I pushed and published my vite plugin for hey api, I noticed that there was also one added to the hey api ecostystem by you a couple of weeks back.

I was not able to find docs on the subject and was wondering on what part of the site would documentation be recommended to be written about this? Maybe under Configuration ?

Furthermore, I think some kind of "retry-on-fail" system (like this) could be of use in there. If you agree, I'd be happy to submit a couple of PR's

[mrlubos]

Documentation, the eternal challenge. I need to figure it out but you're right, it's not documented other than me mentioning it on social media.

I'm not sure what you're trying to do with the retry system? My instinct is to want to have that functionality in the package rather than the plugin – what benefit does it have by being in the plugin?

[Matsuuu]

Ah yeah I guess I was just trying to retrofit the functionality without modifying the library but yeah I think it would be better to have it at library level.

I'll try to set up a repro and maybe even a PR on some kind of a retry system as it would be beneficial to not rely on always having the backend up and running before frontend

[mrlubos]

I'd need to understand the objective of retry before being able to say more. As in, what is the specific problem? I don't think having to start a local server before client is an issue. You can't use the client without it anyway, it's not codegen specific.

[Matsuuu]

I'm mostly thinking of just the situation of "general" dev experience in a "classic" dev env of having a frontend and a backend started together.

Say you have both environments setup as a docker compose setup, and don't have a "relies_on" flag set (or idunno, even with it set, but no proper health checks). If the vite plugin starts before the backend is set up, it will not start in watch mode as it will exit because the initial request didn't go through.

Come to think about it, this might not be the job of the package, but a plugin, like the Vite one. As we kinda want the package to error out if there is no backend to connect to but for development time tooling like the Vite one, it would be beneficial to be just a "Start once, and it runs" experience.

I hope my thoughts came out okay, I'm kind of bad at explaining things

[mrlubos]

Yeah no worries. How would you handle scenarios where I enter an invalid URL so it will never resolve or if the URL is valid but takes a few minutes to resolve?

[Matsuuu]

I'd say the package should handle these like it does right now. Failing out with an error.

But if I were to use it in my Vite plugin (or whatever you want to setup), I'd want it to log the reason for the error while also trying to set itself up again (hence, the retry mechanism).

So the console output on your frontend vite setup would be the sort of

[openapi-ts: HeyApi]: failed to retrieve OpenAPI data: (404: Not Found)

[openapi-ts: HeyApi]: failed to retrieve OpenAPI data: Timed out after 10 seconds (408: Request timeout)

And as soon as it gets a 200 from the openapi endpoint, it would just let the current watch mode take control. And if for some reason that would wet the bed, it would fall back to the vite plugin re-try system

---

I see that the line has the be drawn somewhere on what is the job of the openapi-ts package and what is the job of an external plugin, and this case is something that would maybe be extended at the plugin level rather than risking the package giving false positives

[Menci]

Hi. Maybe I should open a new issue instead, but, I just found the vite plugin hey-api/vite-plugin is NOT watching the input file (e.g. src/api/restful/document.generated.json). When my backend server reloads and writes to this file, the Vite plugin doesn't re-generate the client ts files. Is this not implemented or a bug?

[mrlubos]

@Menci I don't think that was ever implemented and even if it was, clearly it's not working. My preferred fix would be inside openapi-ts and not the Vite plugin so everyone can benefit from it. I also worry that implementing it in both would cause issues. What do you think? Do you want to open a pull request?

[FDiskas]

For me, I can only think about one case why I would like to use the vite plugin instead. As a developer, I have different Swagger URLs for dev, test, and prod. At build time, I would like to get the path to the remote Swagger with a different path for each environment.

Currently on Vite project, I did like that
openapi-ts.config.ts

/** biome-ignore-all lint/style/noDefaultExport: config for https://github.com/hey-api/openapi-ts */
import { defineConfig } from "@hey-api/openapi-ts";
import { loadEnv } from "vite";

const mode = process.env.NODE_ENV || "development";
process.env = loadEnv(mode, process.cwd(), "");

export default defineConfig({
  input: `${process.env.API_URL}/swagger.json`,
  output: "src/client",
  plugins: ["@hey-api/client-fetch"],
});

[mrlubos]

I finally added the Vite plugin to our documentation in #3684 so I'll be closing this issue. Please open a new issue if you have any problems with the Vite plugin!