@hapi/promster@4.1.10 breaking change in patch release when converting to TypeScript

[Iiro Jäppinen]

A patch version increase in @promster/hapi from 4.1.3 to 4.1.10 changed the signature of the hapi's decoration, making the static Promster property instead a function that returns the Promster instance. This seems to have been done in the PR that converted the package to TypeScript.

I added a comment to the PR on the affected line: #352 (review)

packages/hapi/modules/plugin/plugin.ts 
--- server.decorate('server', 'Prometheus', Prometheus);
+++ server.decorate('server', 'Prometheus', () => Prometheus);

Since our software specificed @promster/hapi version ^4.0.0, updating to this broke our application, since previously accessing server.Promster didn't require an additional invocation:

const { Prometheus } = server // the hapi server instance
const reportingService = new ReportingService(Prometheus)

[Iiro Jäppinen]

For now we fixed this by pinning the exact version 4.1.3.

[Iiro Jäppinen]

This change might have been made because the Hapi server's decorate method's TypeScript typings declare the signature of the decorator in this case to be (this: Server, ...args: any[]) => any, even when the docs state it can also be "other value".

[Tobias Deekens]

Thanks for the elaborate issue. This was clearly an unintended accident by me. The migration to TypeScript was a big undertaking and still small issue slipped in. Sorry, for breaking your application.

I presume it was changed to obey to the definitions of Hapi. I am unsure what the actually desired usage is and would have to investigate other plugins.

[Iiro Jäppinen]

I can't promise any time, but having worked with Hapi.js applications I might have some time later to try and see if there's anything that could improve it. It's also a clear bug in the @types definition, since the decorator type doesn't work the same way as Hapi internally.

[Tobias Deekens]

The changeset bot released a new version with your fix. Thanks.