Hey, does anybody have a robust heuristic they use when wrapping a javascript library? I've wrapped ...

# javascript

[Reuben F]

Hey, does anybody have a robust heuristic they use when wrapping a javascript library? I've wrapped several quite easily, but there are edge cases with others that I don't really understand.

For example, https://pouchdb.com/?ref=w3use (npm: pouchdb-browser) looks quite straightforward from the docs, but it doesn't seem to let me apply @JsModule to a package (with a PouchDB object or class), object, class, function, or function property (I get the usual "not a constructor", "not a function", etc). (Right now for this one I made a dynamic using require (val DB = require("pouchdb-browser").default; val db = DB("my_new_db")) and am just delegating to that in a wrapper class, which is fine.) Just an example, but maybe useful to help illustrate the process one can step through to make the JsModule approach work.

[Nikola Milovic]

Idk if this is what you're looking for but writing wrappers isn't really covered much online, check out Dukat and this official repo https://github.com/JetBrains/kotlin-wrappers

And analyze how they write the wrappers for different functions, classes and so on.

[Pitel]

Are you using @file:JsModule?

[Pitel]

I recently encountered one library, where I had to move this @file:JsModule directly above the external class definition to make it work.

[Pitel]

(And remove the file: part, ofc.)

[Reuben F]

@Pitel yeah that's right, I attempted @file:JsModule at the package level, and alternately`@JsModule` when I was trying it as an object, class, or function (right above the respective lines)

[Reuben F]

@Nikola Milovic Dukat doesn't do very well with this particular one - it just pulls the TS definitions from the third party repo and dumps out something non-functional. But ok, I'll look through that repo and see if I see patterns there