OpenFn / OpenFn/adaptors

Generate d.ts for each typedef

Open
#986 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

DevX Needs Priority
Dominant language
JavaScript
Stars
24
Forks
41
Avg merge
3d 13h
Merged PRs (30d)
12

Description

We have started in adaptors to build @typedef declarations to describe object types (usually options). Like this:

/**
 * Options provided to the HTTP request
 * @typedef {Object} RequestOptions
 * @public
 * @property {object|string} body - body data to append to the request. JSON will be converted to a string (but a content-type header will not be attached to the request).
 * @property {object} errors - Map of errorCodes -> error messages, ie, `{ 404: 'Resource not found;' }`. Pass `false` to suppress errors for this code.
 * @property {object} form - Pass a JSON object to be serialised into a multipart HTML form (as FormData) in the body.
 * @property {object} query - An object of query parameters to be encoded into the URL.
 * @property {object} headers - An object of headers to append to the request.
 * @property {string} parseAs - Parse the response body as json, text or stream. By default will use the response headers.
 * @property {number} timeout - Request timeout in ms. Default: 300 seconds.
 * @property {object} tls - TLS/SSL authentication options. See https://nodejs.org/api/tls.html#tlscreatesecurecontextoptions
 */

But this typedef is only used by docs. It cannot be used by Monaco (or other language services) to provide code assist.

We need to find a way to get those typedefs into d.ts files in the built adaptor.

If you look at dhis2, it provides a types.d.ts. This is generated from src/types.ts. Which is great - it means we get code assist for dhis2.create. But the docs do not reflect this, and just say "DHIS2Data" as the type of the argument. Because there's no typedef.

Both structures are sort of needed, but I don't want to duplicate all those typings

The answer to this may simply to be to write adaptors in TypeScript and provide proper type support

Alternatively, we need to auto-generate the typing at build time. It shouldn't be hard to generate a type structure for each typedef. Although I'd actually prefer that we defined types in ts (that's what it for!) and generated docs typedefs from them.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the dhis2 types.d.ts with its src/types.ts source, then inspect how adaptor builds currently package generated output. Define whether TypeScript sources or JSDoc typedefs are authoritative and document the generation path; done means each adaptor exposes usable d.ts types without duplicating declarations or losing the existing documentation types.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
build-system, developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.