wikibase-sdk
wikibase-sdk copied to clipboard
maxlath
Update type definitions for v7
@maxlath @noinkling @EdJoPaTo
In the meantime, you should push a new version without the types key in package.json so as not to give people bad types automatically.
Hello, is there a status on TypeScript typings ? looking around in the issues, it seems there used to be typings but they have been deleted ? It seems also there was typings on DefinitelyTyped but they have been deleted as well ? is there an update on this ?
Thanks for your library ,
@r3mi types were added for v6, but then v7 brought some breaking changes and those types became obsolete so were removed. I don't see any breaking change coming, so if anyone wants to update types for v7, I would be ok to merge them back. I still don't use Typescript for now, so I can't do the maintenance of those, but it seems that enough people are interested to make it happen and keep those updated.
I created the wikibase-types npm package for types returned by the wikibase / wikidata API. Its helpful but still not as good as a fully typed library.
If someone has the time: The typings from #69 could be used to type this library on DefinitelyTyped but without this change the typings seem to get way more complicated than in #69. (Maybe I have overlooked something?)
without this change the typings seem to get way more complicated than in #69. (Maybe I have overlooked something?)
That seems weird to me, usually it's not up to the library to write hacks to ensure compatibility between CommonJS and ES modules. I thought that was what the allowSyntheticDefaultImports TS compiler option did (although there are other options that can enable it implicitly), or maybe esModuleInterop.
These compiler options only help, as far as i understand, to import things into your lib. The types have to be correct for that in the first place. (Correct me if im wrong!)
The problem in this case is the duplicate export of the common types. The library exports methods like isPropertyId and the WDK function and the object returned also contains the common methods.
Normally you would create a namespace and the function with the same name and export that to follow the JS code. But you can not export * from from within namespaces which creates a lot of method: typeof method stubs. On the returned interface you have to do the same which creates a lot of typing code just for that. (which is also prone to errors when something changes)
Having the default export you can simply export * from without the need for the extra namespace and have way less typing code. Also i didnt exported the common methods from the returned object which also simplified the typing code a lot (but thats far from perfect typings).
Personally I think the time invested to type this could be also spent to refactor things. But thats up to everyone themselves. I only started to look differently onto source code since I started using TypeScript and I am not used to code which is used in front end / browsers. The way this library is built certainly has its purpose.