Great idea! I've seen enabled being used in other modules. Is this some kind of hidden convention?

From my perspective, it depends on the module. This one sounds like a good one to have the enabled option, as some users might want to enable it conditionally (e.g. based on the presence of the environment variable for the GTAG ID, or their preference on the environment in which the app runs, i.e. dev/stage/prod).

It would be as easy as adding the following snippet at the start of the module setup function:

if (!options.enabled) {
  return
}

What I generally dislike about this approach for a enabled option is that it breaks auto-imports... I mean, if the user want's to disable the model altogether, he might as well remove it from his Nuxt config? Tricky one. 😄

But yeah, if other modules provide this option that it might be best to add support for enabled to keep the ecosystem aligned.

Would you say more about how this approach might break auto-imports? If we return from the module's setup function early, none of the imports/plugins will be added. Let me know if there's something more to consider here I might have overlooked 😄

And, to be very clear, we are talking about disabling the module conditionally, when the condition is some form of a variable.

I know what you mean now. Yes, the code using whatever this module exports will break when enabled: false. Other alternative would be:

export default defineNuxtConfig({
  modules: [
    'other-module',
    ...(import.meta.env.GOOGLE_ANALYTICS_ID ? ['nuxt-gtag'] : [])
  ]
})

... but, this would mean we would have to add the config with the same condition (and just checked that we lose autocompletion for module config by doing it this way):

export default defineNuxtConfig({
  otherConfig: {},
  ...(import.meta.env.GOOGLE_ANALYTICS_ID ? {
    gtag: {
      id: import.meta.env.GOOGLE_ANALYTICS_ID
    }
  } : {})
})

What do you think?