Skip to content

fix(massimo-cli): declare frontend setter exports in generated types#172

Open
mirko-pira wants to merge 1 commit into
platformatic:mainfrom
mirko-pira:fix/generated-dts-missing-exports
Open

fix(massimo-cli): declare frontend setter exports in generated types#172
mirko-pira wants to merge 1 commit into
platformatic:mainfrom
mirko-pira:fix/generated-dts-missing-exports

Conversation

@mirko-pira

Copy link
Copy Markdown

fix(massimo-cli): declare frontend setter exports in generated types

Problem

For frontend clients (--frontend), the generated implementation file exports three module-level functions:

export const setBaseUrl = (newUrl: string) : void => { baseUrl = sanitizeUrl(newUrl) }
export const setDefaultHeaders = (headers: object): void => { defaultHeaders = headers }
export const setDefaultFetchParams = (fetchParams: RequestInit): void => { defaultFetchParams = fetchParams }

but the generated <name>-types.d.ts never declares them. They only appear as methods on the client interface (setBaseUrl(newUrl: string): void; etc.), which does not describe the module's named exports.

Any consumer whose tooling resolves types from the .d.ts — for example a package that ships the generated client with a "types" field pointing at <name>-types.d.ts — gets TS2305: Module has no exported member 'setDefaultHeaders' on

import build, { setDefaultHeaders } from './client'

even though the symbol exists at runtime. Until now we have been post-processing the generated .d.ts with sed to re-add the three declarations after every regeneration.

Reproduction

massimo openapi.json --frontend --language ts --name api

api/api.mts exports setBaseUrl, setDefaultHeaders, setDefaultFetchParams; api/api-types.d.ts contains no top-level declaration for any of them. Same for --language js (the JSDoc @type annotations reference the interface members, but a .d.ts-only consumer still sees no named exports).

Fix

generateTypesFromOpenAPI in packages/massimo-cli/lib/frontend-openapi-generator.js now emits, right after the client interface:

export declare const setBaseUrl: Api['setBaseUrl'];
export declare const setDefaultHeaders: Api['setDefaultHeaders'];
export declare const setDefaultFetchParams: Api['setDefaultFetchParams'];

The declarations are typed via the interface's own members (same pattern the JS implementation already uses in its JSDoc @type annotations), so they can never drift from the interface.

Tests

  • test/frontend-openapi.test.js: extended the factoryType template in the base test to pin the exact placement of the three declarations, and added explicit assertions in "generate frontend client from path" and in the watt-config test.
  • test/cli-openapi-status-code-204.test.js: updated the expected .d.ts template to the new output.

Full massimo-cli suite: 136/136 passing (node --test test/*.test.js), tsd and eslint clean.

The frontend implementation file exports setBaseUrl, setDefaultHeaders
and setDefaultFetchParams as module-level named exports, but the
generated <name>-types.d.ts never declared them. Consumers whose
tooling resolves types from the .d.ts (e.g. package.json "types"
mappings) got TS2305 errors on
`import { setDefaultHeaders } from './client'` even though the
symbols exist at runtime.

Emit matching `export declare const` statements in the types file,
typed via the client interface's own members so they can never drift
from the interface declarations.

Signed-off-by: Mirko Pira <mp@mirkodev.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant