Been looking at how this can interact with the avvio core as well, automatically adding the methods on register and eg. after – a tricky part is that the .use() (.register() in fastify) both modifies and returns the current instant.

In TS one can assert that the instance is of a specific type, see playground and here:

class MagicAssertion {
  assertMagic(): asserts this is { magic: true } {}
}

// Explicit type apparently needed for assertion to work
const magicInstance: MagicAssertion = new MagicAssertion();

// Error
magicInstance.magic;

magicInstance.assertMagic();

// Not an error
magicInstance.magic;

// Its still a MagicAssertion instance as well
magicInstance.assertMagic();

The assertMagic(): asserts this is { magic: true } means that assertMagic() will either throw or return void.

Its as far as I know not possible to:

• Do the assertion asynchronously through eg Promise<asserts this is { magic: true }> making the assertion async (see Asynchronous type guards and assertion signatures microsoft/TypeScript#37681)
• Do assertion as a side effect and return something else than void on success, eg (asserts this is { magic: true }) | true (see Non‑void returning assertion functions microsoft/TypeScript#40562)

Actually, even assigning the result from magicInstance.assertMagic() seems to break the assertion.

If one were to do:

const app = fastify()
app.register(pluginA)
app.register(pluginB)

Then one could kind of type them as asserts this is MixinsPluginA to ensure app gets the mixins.

But since registration can happen async, the assertion would need to be able to work async, or else it would tell the wrong story.

And since registrations can currently be chained, the assertions would need to happen as a side effect – returning the instance.

The alternative is to return a new type:

const app = fastify()
const appWithA = app.register(pluginA)
const appWithAB = appWithA.register(pluginB)

This works with chaining:

const appWithAB = fastify().register(pluginA).register(pluginB)

But appWithA and app will both retain their old type, even though in practice, when appWithAB has A and B, so has app and appWithA and at every moment a javascript check appWithAB === app will be truthy, while the type system will believe it to not be truthy.

Maybe a hasMixin() like added in this PR is a good first step. Maybe either TS or Fastify should be changed to enable the rest? Or it should be accepted that types and reality will not be a 1:1?

For reference, this is the docs on type narrowing that goes through type predicates, discriminated unions and links out to the blog post announcing assertion functions (added in TS 3.7, but yet to get a description in the documentation itself): https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates

Related comments for plugin and this approach.
fastify/fastify-static#427 (review)

@climba03003 That's more a comment for #5061 I think, as that issue is named Removal of declaration merging

Also: The approach in this PR is different to the one in fastify/fastify-static#427 (review) I believe

The approach in this PR is backwards compatible for publishers and for consumers it could be made so without the need for extra files, eg by having a FastifyInstanceWithMixins type that expose all mixins, or exposing all mixins on FastifyInstance and have a new FastifyInstanceWithoutMixins that works like in this PR

The approach in this PR is backwards compatible for publishers and for consumers it could be made so without the need for extra files

If the plugin types is not updated accordingly to this change, it will still pollute the types globally.
Plugins should be updated as proposed in @fastify/static.

The approach in this PR is backwards compatible for publishers and for consumers it could be made so without the need for extra files

If the plugin types is not updated accordingly to this change, it will still pollute the types globally. Plugins should be updated as proposed in @fastify/static.

This is the approach I took: fastify/fastify-static#469

This is the approach I took: fastify/fastify-static#469

It doesn't conflict my proposed changes to plugin types.
You should allows a way to pollute the global.

That is why I proposed the fastify-global.d.ts and consumer can apply if they need.

@climba03003 Added a rough example on how my approach can provide both a "polluted" global and a type guarded global

If this going to be landed.
The plugins should

1. Provides either mixin types (types: replace declaration merging with mixin types fastify-static#427) or declaration merging the mixin by default (Companion change to fastify PR fastify-static#469)
2. Provides global types that allows simple global pollution.

For 1. , it is not really my concerns. Both can archive the same goal and utilize your PR here.
Provides mixin types is less automate, but it can be less pollute on the mixin utility types.
Pollute the mixin utility types by default provides better DX, because less works for the consumer.

For 2. , the consumer can choose which plugin is globally available.

@climba03003 This PR was meant as a suggested solution to #5061 – if declaration merging should still be possible as the default then that's a discussion that belongs there.

But anyway: I added FastifyInstance['withMixins'] as an example of solving 2 through the solution of 1.

I now also added a AllMixinValues<>, using that one can add all mixins to the FastifyInstance by simply doing:

declare module 'fastify' {
  interface FastifyInstance extends AllMixinValues<FastifyInstanceMixins> {}
}

Closing as too old