-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Description
Ideally Nuxt modules should not be order-dependent but there are a number of situations where users or modules want to change the options of a module (or hook into its hooks). (see #31507)
I would advise that modules which expose one-time hooks should call those hooks in modules:done
to ensure other modules have a chance to register callbacks. (And we need to document this pattern in the module author guide.)
However, there may be modules which want to modify the options of another module, and this is a tricky pattern we're looking to solve.
We are considering:
- a module dependency graph
- tracking module options modification by other modules (and perhaps calling back to that module?)
- ...
However, we would really like feedback from the community and module authors on whether you have modules which are dependent on order. I'd like to know which modules they are and what the use-cases are. This would be very helpful for us as we find a generic solution that will make for a more stable solution (and don't require users to specify modules in a certain order, which is very fragile as an approach).
edit: I'm currently thinking that the order of running modules is a red herring. We should instead allow as a first step, allowing modules to specify dependencies, with the following format:
export default defineNuxtModule({
// ...
// can be an object or a function returning an object:
// (nuxt) => Record<moduleName, { overrides: {}, defaults: {}, optional: boolean }>
dependencies: {
'@nuxt/fonts': {
overrides: {
// any configuration which will override user configuration
},
defaults: {
// configuration which will be merged as long as the user does not set it
},
optional: true // defaults to false
}
}
})
Metadata
Metadata
Assignees
Labels
Type
Projects
Status