Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[q]Autoload with dependencies #31

Closed
SkeLLLa opened this issue Apr 15, 2019 · 7 comments
Closed

[q]Autoload with dependencies #31

SkeLLLa opened this issue Apr 15, 2019 · 7 comments
Labels

Comments

@SkeLLLa
Copy link

SkeLLLa commented Apr 15, 2019

Fastify plugin module support dependencies section. If some plugins wrapped with fastify-plugin registered through autoload, then it checks only plugins, that are loaded through autoload. However it ignores plugins that are previously loaded with fastify.register.

Is that correct behaviour? Or it should check Symbol(registered-plugin) in fastify instance as well?

@mcollina
Copy link
Member

Can you make an example where this behavior is failing you? How would you change this?

@SkeLLLa
Copy link
Author

SkeLLLa commented Apr 16, 2019

@mcollina
Consider we have the following structure

const fastify = require('fastify')();
const externalPlugin = require('fastify-external-plugin');
const autoloadPlugin = require('fastify-autoload');
fastify.register(externalPlugin);
fastify.register(autoloadPlugin, {dir: './plugins'});

... // await for fastify.ready and listen

As an fastify-external-plugin we could have fastify-mongo plugin, for example, and couple of own custom plugins are loaded through autoload plugin from plugins dir. Our own plugins depend or use functionality from fastify-mongo module. So in that case we should define dependency on fastify-mongo module. And now fastify-autoload plugin will search that module inside directory provided in options, but it will not check modules registered through fastify.register function.

Obviously we can set dependency to decorators and wait until fastify.mongo decorator will be available. However I think there could be a case when our custom plugins could depend on some other plugin that doesn't decorate fastify instance.

@mcollina
Copy link
Member

Fastify does not resolve the dependency graph, because plugins are loaded in-order by fastify. This plugin needs that, because it would load them from the order that they are being returned from the file system.

Essentially, the dependency order thing is needed to solve a problem added by autoload, and only on plugins registered by autoload.

If you need fastify.mongo before the plugins returned by autoload, then register it before then. Maybe I'm not really understanding your issue. Would you mind crafting a little repo?

@salmanm
Copy link
Member

salmanm commented Apr 16, 2019

I realise what @SkeLLLa means is if we have a plugin as

const fp = require('fastify-plugin')

function plugin (f, opts, next) {
  // plugin body

  next()
}

module.exports = fp(plugin, {
  name: 'plugin-g',
  dependencies: ['fastify-sensible']
})

The new feature of automatically resolving dependencies won't find fastify-sensible in the list of available plugins, because its being registered manually.

The problem sounds legit. Do you have any suggestion on how to tackle this? @mcollina

@mcollina
Copy link
Member

I think the best suggestion if a plugin is missing is to assume that is loaded by fastify and rely on https://github.com/fastify/fastify/blob/e2062efcc7adbb82101e3afd7734835f81d71bbe/lib/pluginUtils.js#L29 this check. It will throw if it's missing, and that's ok.

@salmanm
Copy link
Member

salmanm commented Apr 16, 2019

Yea that sounds good. Something like this? #32.

I'll add test if the PR is fine. Done.

@stale
Copy link

stale bot commented Oct 21, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 21, 2020
@stale stale bot closed this as completed Nov 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants