Register modules via package.json
galvez opened this issue · comments
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
.
To prevent problems, having modules
or devModules
in nuxt.config.js
would automatically override the package.json
config.
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...
@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.
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 */
}
}