How to separate TypeScript definition of an utility micro from the actual implementation

[rams23]

The new version of create-single-spa outputs type definition and this is great to be used in another typescript micro.
If a microA depends on the utility micro (i mean literally in the package.json), the typescript definition will be automatically discovered, but you add an explicit relation between the two micro, and when you release the utils you need to update the dependency in the microA. If we have a separate deploy and a SystemJS based import, the dependency is only on types, not the implementation, because the actual code is loaded dynamically at runtime.
Is there a smart way to depends only on external exported types and not on the actual implementation? like having a separate package for the external micro interface and another for the implementation, so that the microA must be updated only if that interface changes. Have you ever considered creating such a setup, even if the maintenance of the package is more difficult, the management of the entire application will improve i think. It's like the application of the dependency inversion principle applied to a package.

[joeldenning]

As of right now I don't think typescript has a way of loading types remotely. Here's an issue that discusses it: microsoft/TypeScript#28985

@frehner has explored creating an open source tool that would automatically keep types up-to-date without having to republish npm packages and then upgrade all dependencies. However, I don't think such a tool exists yet. If someone knows of one, please share!

[frehner]

After experimentation and stuff, in the end I just went with the traditional publish-types-to-npm method; it's the default and widely supported method of distribution, and any tooling I would have built probably wouldn't have worked as well anyway.

[rams23]

Thanks for your response! I'm working on a single-spa POC, implementing an app using jsonplaceholder APIs. I also looked at something like this microsoft/TypeScript#420, to manage the module external module interface separately and then implement it.

I ended up creating a simple script that uses rollup and rollup-plugin-dts to export the external module definition. The idea is to use it to create a separated package like {libraryName}-types that will be the actual dependency of the other micros and libraries, versioned according to the external types and not to the implementation. I just started it so sorry for the no doc /no anything but here it is: https://github.com/xtreamsrl/mfe-sspa-poc/blob/main/libraries/package-type-generator/index.js. For example, I have an ui-kit library and an ui-kit-types package, the ui-kit-types package is generated automatically using the script and contains the exported types from the auth. auth-types is used as a dependency inside the micros.