Before filing issues, please check the following points first:

• Have a look at https://github.com/wycats/handlebars.js/blob/master/CONTRIBUTING.md
• Read the FAQ at https://github.com/wycats/handlebars.js/blob/master/FAQ.md

Since the 4.0.13 and 4.1.0 releases, there are now two "sources of truth" for types - @types/handlebars and handlebars, as the project has taken handlebars.d.ts back into its lib area with this release. A module can end up picking up both packages through dependencies. TypeScript is presented with two places claiming to define the handlebars types, which leads to a spate of messages during the build.

I am told there is some kind of deprecation process over at StronglyTyped that may help with this confusion, but I do not know the details or whether it offers a practical solution. For the time being, I'm using the resolutions section of my package.json to freeze the version of handlebars used within my project at 4.0.12. This quells the confusion, but this cannot continue forever.

I'm not sure if a more cleanly orchestrated solution can be found, but the parsed contents of the version delivered in 4.0.13 / 4.1.0 is byte-for-byte identical to the version in @types/handlebars. Only the comments differ. This suggests that, if it would help, little might be lost by backing out the current behavior before introducing the transition in a more coordinated way.