CODEWITHSUNDEEP
typescriptnpm
frqstbite
frqstbite

Reputation: 1

Distribute types for API while avoiding redundancy

I'm designing a Typescript program that takes in "extensions" of sorts, importing the index.js file from their root folders and using the returned object to instantiate the extension. I want extension developers to be able to create an empty node project and import the API-relevant types from a package I distribute on npm, as it sounds like an ideal developer experience to me. The hiccup is figuring out what to put in those types and how to structure them.

At first, I thought it may be a good idea to distribute a folder of .d.ts files as a package and call it a day. The main program can install the package to design the implementation, and the extensions can each install it to design their functionalities.

This has a flaw, though. I consider the main program to be the source of truth for this API - after all, the extensions are designed to run with this program, not necessarily to fit some arbitrary API spec. With the current approach, I have to extract specific pieces of the main program out into this random API space instead of giving the extensions access to the real types used by the real program. Also, when designing the real program, I would be forced to make everything extend those previously declared types to ensure type safety, which is just plain redundant.

Any thoughts on a different way to approach this?

Upvotes: 0

Views: 36

Answers (1)

Dimava
Dimava

Reputation: 10909

You may use https://www.npmjs.com/package/@microsoft/api-extractor to bundle all exported types into a single d.ts file

Upvotes: -1

Related Questions