Open joffrey-bion opened 1 year ago
I think I can try to get array of modules and generate d.ts
file with this content:
import "rxjs"
import "rxjs/ajax"
And after that I can put this file in typescript program, and typescript will resolve all files using its own mechanics
1) How to handle
exports
field inpackage.json
link 1 link 2
I wasn't aware of the exports
field (admittedly I'm not an expert in the JS / npm ecosystem).
But if I understood correctly, this field doesn't relate to types. It seems it's only there to provide the correct javascript (not ts) entrypoint when importing the library via different module systems. So it's irrelevant for karakum, right?
Or did I miss something and karakum can actually process pure JavaScript as well in addition to typescript?
Ah wait I read a bit more and indeed each entry in the exports
array can have a types
property with a path to a .d.ts
. I think that Karakum could use these too.
I don't see a problem with multiple .d.ts
files as input to Karakum. Can't Karakum generate as many Kotlin files as input .d.ts
files?
There is no problems with multiple TS files as input so far.
I see two problems here: 1) What to do with dependencies (converting NPM package can contain references to types from another NPM packages)? I need some mechanics to avoid generation of whole dependency tree by default 2) Type resolution logic becomes more and more difficult, I don't want to re-implement all Node module resolution rules and TypeScript resolution rules too. So I would like to reuse exiting mechanics somehow.
NPM modules have a
typings
(ortypes
) property in theirpackage.json
to define a path to the.d.ts
file describing the types for the module: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#including-declarations-in-your-npm-packageIt would be nice if Karakum could figure out the path on its own based on that, so the config could just be the name of a package instead of the users having to inspect the
package.json
of each module on their own and update the path to the typings file in case it changes in the original package.For instance, a basic Karakum config could simply be:
And both the
input
path and thelibraryName
could be derived from theinputModule
.Of course, we could offer optional configuration to override the path to the
node_modules
, or override the input path to the declarations if need be. But as a default that would be great.