Is it an autoloader or a fastify-cli related issue?
Maybe we should transfer this issue?

@jean-michelet

@fastify/autoload is relying on a Node.js internal variable to check if a module is loaded.

https://github.com/nodejs/node/blob/be7a0c578026dda29a1c9e76d5a0e04b71f25601/lib/internal/process/pre_execution.js#L259-L265

I don't think this is fastify-cli's issue since -r in fastify-cli is not guaranteed to be exactly the same as the -r in node, but it would be great if it's possible for fastify-cli to require modules the same as node does.

If not, maybe fastify-cli can provide another way for plugins to check for loaded modules, or @fastify/autoload can use another method to detect specific modules.

If no answer from other collaborators, are you willing to investigate and push a PR on the right repo plz?

Imitating Node.js behavior by adding the following lines in fastify-cli's preloadCJSModules() does solve this issue, but I don't know if this is the right way to solve it.

I'll wait for more comments.

Object.defineProperty(process, '_preload_modules', {
  __proto__: null,
  writable: false,
  configurable: true,
  enumerable: true,
  value: opts.require,
})

I don't know if this is the right way to solve it.

Wdyt @mcollina?

I still think this issue should be transfered to fastify-cli imo.

I have to manually set the FASTIFY_AUTOLOAD_TYPESCRIPT environment variable.

Or we can also document this workaround here.

I think the problem is in this repo, we should not be checking that. Maybe we should check the require cache as well.

Looking into it

Now I believe we should solve it in fastify-cli, because once require is called, the info of module name is lost and become many absolute paths in require.cache, checking it will become inefficient and non-trivial.