Use the `typings` section of `package.json` instead of a path

[joffrey-bion]

NPM modules have a typings (or types) property in their package.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-package

It 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:

{
  "inputModule": "@blueprintjs/icons",
  "output": "generated"
}

And both the input path and the libraryName could be derived from the inputModule.

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.

[sgrishchenko]

I like this proposal, but I have couple of questions: 1) How to handle exports field in package.json link 1 link 2 2) What if package contains few entrypoints (e.g. rxjs + rxjs/ajax)

[sgrishchenko]

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

[joffrey-bion]

1) How to handle exports field in package.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?

[joffrey-bion]

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?

[sgrishchenko]

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.