Migration: @kubb/plugin-client removed

@kubb/plugin-client no longer ships. Two dedicated plugins replace it:

• @kubb/plugin-axios generates an axios HTTP client. Import pluginAxios.
• @kubb/plugin-fetch generates a Fetch API client. Import pluginFetch.

Both speak the same RequestResult contract and share the same options: output, exclude, include, override, baseURL, parser, sdk, group, resolver, and macros.

Pick a plugin by the old client value

The old client option chose the runtime. Now you pick the plugin instead.

Before (axios)

import { pluginClient } from '@kubb/plugin-client'

pluginClient({ client: 'axios', output: { path: 'clients' } })

After (axios)

import { pluginAxios } from '@kubb/plugin-axios'

pluginAxios({ output: { path: 'clients' } })

Before (fetch)

import { pluginClient } from '@kubb/plugin-client'

pluginClient({ client: 'fetch', output: { path: 'clients' } })

After (fetch)

import { pluginFetch } from '@kubb/plugin-fetch'

pluginFetch({ output: { path: 'clients' } })

Rename sdk.className to sdk.name

The sdk option keeps the same shape with one rename. className becomes name, and the value is lower-case.

Diff

- pluginClient({ sdk: { className: 'PetStore' } })
+ pluginAxios({ sdk: { name: 'petStore' } })

The clientType: 'class' behavior now lives behind sdk. Set sdk to generate a class-based SDK on top of the operation functions.

Removed options with no replacement

These plugin-client options are gone and have no equivalent:

• operations
• clientType: 'staticClass'
• the custom-client importPath
• urlType, with its get<Operation>Url helpers and the resolveUrlName resolver method

Drop them from your config. If you wrapped a custom HTTP library through importPath, move that logic into your own module and call the generated functions from it.

Rebuild the URL helpers with a custom plugin

urlType: 'export' used to emit one get<Operation>Url function per operation that returned the URL without sending the request. The client plugins no longer generate those. If you relied on them, generate the same helpers from your own plugin. The URL lives on each operation node as node.path, so a small operation generator covers it.

pluginClientUrl.ts

import { , ,  } from '@kubb/core'

export const  = (() => ({
  : 'plugin-client-url',
  : ['plugin-ts'],
  : {
    'kubb:plugin:setup'() {
      .(
        ({
          : 'client-url-generator',
          (, ) {
            const  = .('plugin-ts')
            const  = `${.(., 'function')}Url`

            return [
              ..({
                : `${}.ts`,
                : `${.}/${}.ts`,
                : [
                  ..({
                    : [..(`export function ${}() {\n  return \`${.}\` as const\n}\n`)],
                  }),
                ],
              }),
            ]
          },
        }),
      )
    },
  },
}))

Register it alongside pluginTs and your client plugin. For a full walk-through of the plugin anatomy and how to read names off the plugin-ts resolver, see Creating plugins.

Query plugins keep client

@kubb/plugin-react-query, @kubb/plugin-vue-query, and @kubb/plugin-swr keep a client?: 'axios' | 'fetch' option. It auto-detects the registered client plugin, so register pluginAxios or pluginFetch alongside the query plugin and the hooks pick it up.

plugin-mcp

@kubb/plugin-mcp now takes client as an 'axios' | 'fetch' selector instead of an object. Set baseURL at the top level of pluginMcp. The handlers delegate to the registered axios or fetch client.

Diff

- pluginMcp({ client: { client: 'fetch', baseURL: 'https://api.example.com' } })
+ pluginMcp({ client: 'fetch', baseURL: 'https://api.example.com' })