/**
 * Node-only convenience for inpax's EdiabasXProvider.
 *
 * Lives in a separate subpath (`@emdzej/inpax-ediabasx-provider/node`)
 * so the main entry stays browser-safe — `@emdzej/ediabasx-ediabas/node`
 * pulls in `node:fs`, which would otherwise show up in any Vite/webpack
 * bundle that imports the provider.
 *
 * Browser callers build their own `IEdiabas` (typically
 * `EmbeddedEdiabas` with a `loadSgbdResolver` reading from a
 * `FileSystemDirectoryHandle`, or `EdiabasClient` against a remote
 * server) and hand it to `new EdiabasXProvider({ instance })`. This
 * helper is the Node analogue — load an `ediabas.config.json`, build
 * the configured interface, wrap it in `EmbeddedEdiabas`, pass to the
 * provider.
 */
import { EdiabasXProvider, type EdiabasXProviderConfig } from './ediabasx-provider.js';
export interface NodeEdiabasXProviderConfig extends Omit<EdiabasXProviderConfig, 'instance'> {
    /**
     * Path to an `ediabas.config.json` file. Loaded via
     * `@emdzej/ediabasx-ediabas/node`'s `loadConfig` + interface
     * factory — same shape `ediabasx run` consumes, so a single
     * config drives both the standalone CLI and inpax scripts.
     */
    configFile: string;
}
/**
 * Build an EdiabasXProvider from a JSON config file path.
 *
 * Decomposed from the upstream `createFromConfigFile` so we can build
 * an `EmbeddedEdiabas` (implementing `IEdiabas`) instead of a bare
 * `Ediabas` — the provider's surface is `IEdiabas`-only since 0.7.0
 * of the consumer side.
 */
export declare function createNodeProvider(config: NodeEdiabasXProviderConfig): Promise<EdiabasXProvider>;
export { EdiabasXProvider, Inp1Adapter } from './index.js';
//# sourceMappingURL=node.d.ts.map