How is this different than using https://github.com/fastify/fastify-autoload ?

@cemremengu You don't need to write

module.exports = function (fastify, opts, next) {

The fastify instance gets injected.
For me module.exports does not look clean.

Edit:
And I use globs, fastify-autoload only loads a hole directory. You have the possibility to use ignorePattern, but I think the glob approach is better.

I'm kind of -1 into publicizing modules that monkeypatch the Node.js loader. I would discourage people to use this: https://github.com/TheNoim/fastify-loader/blob/master/inject.js.

Also, exporting a function and passing in the fastify instance ensures that multiple copies of the same fastify app could get started (in tests, for examples).

@mcollina

I would discourage people to use this

You can. But everyone propably should decide on their own.

Also, exporting a function and passing in the fastify instance ensures that multiple copies of the same fastify app could get started (in tests, for examples).

Yes this is right. But in most cases, this isn't needed. You can see this more like an: I want to make a quick webserver for a small project with as less stumbling stones as possible.

Yes this is right. But in most cases, this isn't needed. You can see this more like an: I want to make a quick webserver for a small project with as less stumbling stones as possible.

This is needed in most cases, as it will prevent writing effective unit tests.

It is possible to achieve something very similar with the use of the vm core module and a Proxy object for the global context. I would recommend pursuing that route instead (and it would indeed be very cool). It might require a bit more code, but it would support writing tests effectively.

This is needed in most cases, as it will prevent writing effective unit tests.

Pff.. Untis test, my most hated thing. :P

Edit:

You can pass multiple fastify instances. You can change the instance name.

It is possible to achieve something very similar with the use of the vm core module and a Proxy object for the global context. I would recommend pursuing that route instead (and it would indeed be very cool). It might require a bit more code, but it would support writing tests effectively.

This was the first thing I tried. But if you provide a context, it gets sandboxed. This prevents to apply changes made to the fastify instance. The only alternative would be eval. But eval has access to the lcoal scope. Another alternative is vm2. The problem with vm2 is, you need to mock __dirname and __filename. Oh you don't need to.

@mcollina Updated the module. Replace this "hacky" method with vm2.

Good work! It would be fantastic to add a unit test to load 2 fastify apps in the same process ;).

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.