Refactoring the component

[jean-michelet]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched existing issues to ensure the issue has not already been raised

Issue

The code is becoming increasingly difficult to maintain, I think it deserves a redesign as suggested here and here.

I'd like to know if you have any suggestions before proceeding, we could also consider proceeding step by step.

[Uzlopak]

I dont see the maintenance problem. The code is actually of very high quality. Also it is "only" about 500 LOC. The issue is that the problem it tries to solve is complex itself. That results in not seeing every "edge" case.

[jean-michelet]

Perhaps I should have expressed myself less assertively. I have the feeling that the code could be better organized and more readable, but this not the reason I want to invest time in it. Would refactoring help solve the issue problem and eventually add new features? If yes, how?

Maybe you can elaborate what you were thinking by saying this @climba03003:

Rework the files finding and tree building - it is the critical one because all the information is scattered currently.

[climba03003]

The main problem is that the current information split into two array. https://github.com/fastify/fastify-autoload/blob/13706979a74cfac4c414d9114480c04f2c52833d/index.js#L26-L27 Sometimes the information is not able to find inside some function.

For what I propose is that we should define the works into 3 clear steps.

1. Finds all available files including the config.
2. Build the tree based on step 1. and the plugin config
3. Registered plugin based on the tree in step 2.

In this case we can always change the function inside step 2. to provide different behavior instead of looking around different function and gather necessary information in different place.

In step 2, the tree building output should be something like,

interface Node {
  prefix: string
  pluginDir: string
  func: FastifyPluginAsync
  hooks: FastifyPluginAsync[]
  children: Node[] // it should be used in some plugin options only
}

// most of the time each prefix is using only one func
type PluginTree = Node[]

[jean-michelet]

I agree that hooks should be composed to plugin tree before registration step.

Build the tree based on step 1. and the plugin config

Btw, do you think we should allow auto exports from autohooks files too?

export const autoConfig = { name: 'y' }
export const autoPrefix = "/prefixed";

I am not sure that it's a good idea but some people want to use them there, I saw this in a reproduction issue repo.

If we don't maybe we should throw a clean error to educate users when they try to export such variables.

[climba03003]

Btw, do you think we should allow auto exports from autohooks files too?

It is not a good idea to permit hooks having different config or prefix than the index plugin. The main reason is that it is very easy to misconfig, for example you may experience some path only contain hooks but no route.

[jean-michelet]

Do #401 opened more possibilities to fix #326? I will investigate this week but maybe you have some feedbacks since.