-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Firstly I'd like to thank all the contributors for creating such a fantastic project, it's really stood the test of time & has been paramount in the construction of many rich UIs, you've done yourselves proud.
Currently the @types package declares an ambient module "knockout" before exporting with export = (exports a single object in CommonJS/AMD format). I'm not sure if the ambient module part is required / recommended, so I've carried out some research on modern declaration authoring practices.
For advice relating to choosing a UMD template, see https://www.typescriptlang.org/docs/handbook/declaration-files/templates/global-plugin-d-ts.html#examples-of-umd-libraries. Looking at the v3.5.1 .js dist, I believe we need to expose a object so the module template provided here is most appropriate https://www.typescriptlang.org/docs/handbook/declaration-files/templates/module-d-ts.html#default-exports.
There appears to be a choice when authoring whether to use the new ESM default export syntax with esModuleInterop:true or export =, I would have thought the latter is the best choice for backwards compatibility.
My question why does the current definition @types/knockout/index.d.ts v3.4.71 define an ambient module? Can the export as namespace myLib syntax be used to handle global usage (when used without a module loader)? If you'd like some examples look at chart.js/jquery/moment.
Secondly I noticed the official npm knockout package includes types but defines them rather differently, which package should consumers use going forward?
Thanks in advance!