import type { Plugin } from 'vite';
interface Options {
    srcDir: string;
}
/**
 * Stable id for a `'use server'` module: a project-root-relative POSIX path
 * (e.g. `src/api/actions.ts`). This is what the client stub embeds in its
 * `fetch()` call and what both the dev middleware (below) and the prod
 * server (assets/prod-server.mjs, keyed off the registry built by
 * cli/build-server.ts) use to look the module back up — it has to be
 * identical in dev and prod, so an absolute filesystem path (which used to
 * be used here) doesn't work since it's dev-machine-specific and wouldn't
 * match a module bundled into a prod registry anyway.
 */
export declare function toActionId(absPath: string, projectRoot?: string): string;
/**
 * Detects `'use server'` at the top of a module and splits it:
 *  - the client bundle gets a `fetch('/__murasaki/action/…')` proxy
 *  - the server keeps the real implementation (the SSR transform is left
 *    untouched so `server.ssrLoadModule` can load the actual functions)
 *
 * In dev, a middleware handles the `fetch` calls emitted by the stub and
 * invokes the real function via `ssrLoadModule`. In prod, the same stub
 * hits a Node HTTP server (assets/prod-server.mjs) backed by a registry
 * bundle built ahead of time by cli/build-server.ts.
 *
 * Full RSC parity lands in Phase B — Phase A ships the wire format so the
 * public shape is stable from day one.
 */
export declare function serverActionsPlugin({ srcDir }: Options): Plugin;
export {};
//# sourceMappingURL=server-actions.d.ts.map