Register modules via package.json

[galvez]

Introduce a small change to @nuxt/config that infers if ${rootDir}/package.json has nuxt.modules or nuxt.devModules, loads it and merges them into the config automatically.

This would allow for some modules to to self register into Nuxt applications without having to modify nuxt.config.js (or, without requiring nuxt.config.js to exist in the first place).

Usage example: installing @nuxt/press could update package.json to include:

"nuxt": {
  "modules": ["@nuxt/press"]
}

So users of @nuxt/press could use press.config.js (example) without requiring to have a full blown nuxt.config.js file (for most simple uses).

This opens up a path for specialized modules to be used/implemented as micro frameworks with Nuxt as a core framework. These specialized modules could offer configuration via their own file without requiring users to have nuxt.config.js.

[galvez]

To prevent problems, having modules or devModules in nuxt.config.js would automatically override the package.json config.

[atinux]

I am not against nor in favour of this right now 😄

We have to dig more into it and see potential issues. What I really like is the possibility to use Nuxt as a core framework to open the micro frameworks area.

Infos about vue-cli: https://cli.vuejs.org/config/#vue-config-js

vue.config.js is an optional config file that will be automatically loaded by @vue/cli-service if it's present in your project root (next to package.json). You can also use the vue field in package.json, but do note in that case you will be limited to JSON-compatible values only.

Actually I think this is a bad conception since users will struggle more to look at where the config is...

[galvez]

@atinux I thought about opening up the nuxt key in package.json for everything with the JSON-compatible values limitation.

Actually I think this is a bad conception since users will struggle more to look at where the config is...

But I gave up exactly because of this. We just need to allow modules to do this. This should be a modules-focused feature, not recommended for general use. You either have "nuxt" in package.json for specifying a module, or full-blown nuxt.config.js.

Each module that uses this feature can dictate what options to load.

[pi0]

Adding a 3rd config source (other than nuxt.config. and config/) confuses users and prevents to directly configure nuxtjs (like adding analytics module or even setting router base or some meta) unless module supports the option or user bothers creating an additional nuxt.config file again! (and maintain package.json + nuxt.config.js + press.config.js)

Actually, We would consider supporting package.json as a source of configuration in config refactor (#16) but there are some concerns:

• Confusing users to search where is exactly config
• Limiting to serializable only options when using pkg.json
• What is source priority when merging package.json/nuxt.config/config?
• When adding config write support, which one should be updated?
• Branding and division of nuxt configuration methods
• Is delegating config handling to modules safe and would be consistent? Like how to load press.config.* / how types apply / how they validate config (something which is planned for config enhancements)

For a module like nuxtpress what's wrong if we create config/press.js or add a press section to nuxt.config? IMO is really more readable to have below config rather than a separate press.config.js + a hidden nuxt section in package.json

export default {
  modules: [
    '@nuxt/press',
    '@nuxtjs/google-analytics'
  ],
  analytics: {
    id: ''  
  },
  router: {
    base: '/blog'
  },
  press: {
    /* nuxt-press configuration */
  }
}