#2588·knockout

@types/knockout npm package declared as ambient module instead of exporting namespace

Author: andy1547Created Feb 14, 2022Updated Feb 14, 2022

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!