I know it's strange to work like this, because the purpose of decorators is precisely to... decorate...
But, for me, it's important not to force Fastify users to use decorators to get features from core plugins.

It does fit better on a Vanilla JS project, but not with typescript imo. The goal is not to create a new design, but to tell the users that we are not forcing them to use decorators with module augmentation and there is an alternative if they prefer.

getDecorators, in my mind is getUtils or getConfig. The reference to decorators is accidental, it's just an adaptation around the existing, wich can be stated clearly in the doc.

The title says allow to access decorators before start, but this is already possibile

Not request and reply decorators, at least not in a formal way, we could use key symbols kReply and kRequest but I wouldn't recommend to depend on internal components.

isn't this example already doable?

const sendFile = fastify.sendFile as StaticReplyDecorators
fastify.get('/', (request, reply) => {
  return sendFile.call(reply, 'hello.html')
})

Unless the plugin has decorated the fastify instance with a function that depends on Reply as this context, your example will return undefined. You don't have a check to ensure the decorators exists at registration, although achievable with fp, isn't it better to resolve runtime/compilation check in one place?

But yes, we could allow via an option to set decorators to the current instance instead of Request/Reply prototypes/props.

I also realize thanks to your comment that my implementation is wrong, because two decorators a can exist on instance, request and reply:

fastify.decorate('a', 'from_instance')
fastify.decorateRequest('a', 'from_request')

fastify.getDecorators('a') // from_request is never found

So, we should have getRequestDecorators and getReplyDecorators.

Yes, I agree.

There is no need to have this API for the fastify instance because one could always do instance[name].

There's an advantage to access it via getFastifyDecorators as there's a check to verify that the decorator is accessible. But unlike Request/Reply, there is no need to expose it. So I can understand you would prefer to leave the responsibility to the end-user, let me know and I remove it.

I understand the skepticism about giving access to Request/Reply decorators, and there's no hurry, I can work on convincing you more.

This might not be used directly by users, but by a plugin offering a slightly different architecture to work with Fastify (I need to think/read about it). But for this to happen, it would be great to be able to offer adapters capable of wrapping the many features of Core plugins on Request/Reply as changing/duplicate an entire ecosystem is not an option. This my main concern and the reason for this PR.

In the meantime, here are a few examples.

A logger plugin that decorate instance:

export interface FastifyLoggingDecorators {
  log(message: string): void;
}

export const FASTIFY_LOGGING_DECORATOR_NAMES = ['log'];

const fastifyLoggingPlugin = fp(async (fastify: FastifyInstance) => {
  fastify.decorate('log', (message: string) => {
    // implement the logic
  });
});

export default fastifyLoggingPlugin;

An auth plugin that decorate request:

export interface RequestAuthDecorators {
  getAuthenticatedUser(): { id: string; name: string } | null;
}

export const REQUEST_AUTH_DECORATOR_NAMES = ['getAuthenticatedUser'];

const requestAuthPlugin = fp(async (fastify: FastifyInstance) => {
  fastify.decorateRequest('getAuthenticatedUser', function (this: FastifyRequest) {
    // Implement the logic here
    return null;
  });
});

export default requestAuthPlugin;

A static file handler plugin that decorate reply:

export interface ReplyStaticDecorators {
  sendFile(filename: string, rootPath?: string): FastifyReply;
}

export const REPLY_STATIC_DECORATOR_NAMES = ['sendFile'];

const replyFormatPlugin = fp(async (fastify: FastifyInstance) => {
  fastify.decorateReply('sendFile', function (this: FastifyReply, filename: string, rootPath: string = './') {
    // Implement the logic here
    return this;
  });
});

export default replyFormatPlugin;

Then, a plugin to configure routes:

const routePlugin = fp(async (fastify: FastifyInstance) => {
  // Get all the necessary dependencies with compilation/runtime check
  const { log } = fastify.getFastifyDecorators<FastifyLoggingDecorators>(FASTIFY_LOGGING_DECORATOR_NAMES);
  const { getAuthenticatedUser } = fastify.getRequestDecorators<RequestAuthDecorators>(REQUEST_AUTH_DECORATOR_NAMES);
  const { sendFile } = fastify.getReplyDecorators<ReplyStaticDecorators>(REPLY_STATIC_DECORATOR_NAMES);

  fastify.get('/user', (request, reply) => {
    const user = getAuthenticatedUser.call(request);
    if (!user) {
      log('Unauthenticated access attempt');
      return reply.send({ success: false, message: 'Unauthorized' });
    }

    log(`User profile accessed by ${user.id}`);
    return sendFile.call(reply, 'user-profile.html', '/views');
  });
});

export default routePlugin;

Not to be a hard opposer of the feature, but I'm still having hard times seeing use cases for these new APIs.
Nevertheless I believe there's a use case that can be interesting and its to verify dependencies between plugins.

If e.g. there's plugin A that depends on B decorating the FastifyRequest object, plugin A can use fastify.getRequestDecorators to validate the decorator exists and throw or handle something different otherwise.

It might overlap already to what fp already offers; but we can make that, instead of overlapping, fp can rely on this for more strict checks.

Besides that, I'm having some troubles seeing more complex use case around it.

If the solution in this PR is right and applicable to all the core plugins, I might be happy enough to close this PR by myself.

Can you take a look?

My recommendation has not been implemented yet: #5768 (review).

I think we could have:

const { sendFile } = reply.getDecorator(..)

In this way: sendFile could be automatically bound to reply (use a proxy and lazily bind them on first access), completely avoiding call.

#5672 is likely going to be semver-major.

I've started looking into Node DI containers, and I think it's possible to create something really satisfying with Fastify for people who prefer this way of developing an application.

Closing for #6019.

Sorry, I reopen it 😛

Reading the comment of jsummers on the last mentioned issue, I think we still can allow access to decorators to simplify typing and dependency check, for business logic too. IoC container is an other topic.

No need for module augmentation here:

fastify.getDecorator<SomeFeature>('someFeature') // great for dependency check at registration
request.getDecorator<SomeFeature>('someFeature')
reply.getDecorator<SomeFeature>('someFeature')

I am gonna implement it the way Matteo recommend it.

I think, we should add a method Request.setDecorator only allowed when the application is ready for this kind of use case:

fastify.decorateRequest('sessionData', null)
fastify.addHook('onRequest', async (req, reply) => {
  req.setDecorator<ISession>('sessionData', { user: 'Alice' })
}

Cleaner than using as keyword, eg.:

(req as typeof req & { someProp: string }).someProp = 'hello'

In order to explain the evolution of my thinking, I initially wanted to propose something that would allow more control over the typing and runtime safety of both business logic and installed core plugins.

But I think it's possible to decouple core plugin utilities if desired by the users of the framework.

I've explained my reasoning a little further in the updated doc, I'll read your feedback carefully.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.