Improve Config Package #16
Comments
Might be hard (for now) because of modules which can freely choose their used keys. |
|
@manniL Exactly. At least the top level object cannot be strictly validated. We might add a special Example: {
__validate__: {
_strict: false, // <-- Allow modules freely adding new keys for BW compat
build: { type: Object }
},
build: {
__validate__: {
_strict: true, // <-- Indicates no extrra options are accepted
name: { type: String, required: false },
old: { type: String, deprecated: true }
}
}
}We can also think about using a 3rd party schema validator that is able to generate types too. Like joi + |
|
Supporting Example: config/
build/
babel.js
pages.js
app.jsThis logic could use directly glob right inside @nuxt/config. So writing configuration could also feel like writing pages <3 |
|
@Atinux Nice, I really liked how @manniL went with his own website with a |
|
I would be wary of using a directory called https://www.npmjs.com/package/config I've used the Perhaps // nuxt.config.js
import generate from "./nuxt/generate"
import hooks from "./nuxt/hooks"
import head from "./nuxt/head"
import env from "./nuxt/env"
export default {
srcDir: "src",
generate,
hooks,
head,
env
} |
|
@wagerfield If we implement that feature, the directory name will be changeable |
|
Another thing that might come in handy: A |
|
@manniL EDIT : might have misunderstood |
|
@kevinmarrec I thought about sth. like an argument that every sub-function could take (if it's written as function) so the subconfigs would be sth. like I saw that @Timkor (hope that was the right handle 🙈) applied such a pattern: const context = require('./shared/utils/context');
context.print();
module.exports = {
server: require('./config/server.js')(context),
env: require('./config/env.js')(context),
/*
** Headers of the page
*/
head: require('./config/head.js')(context),
// Sitemap settings:
sitemap: require('./config/sitemap.js')(context)
} |
|
Oh yes right ! I'm now thinking of a new behavior for subconfigs 🤔 What about // config/build.js
export default function (config, context) {
config.build = {
property: context.value
}
return config
}The idea is to read every files in config folder and merge the values to build the final configuration file. People could preprend their filenames with numbers in cases they need to override same configuration properties in certain order in different files (rare case but could happen) EDIT : It would work likely like Webpack extend config |
|
Further to the discussion in #10 @pi0 suggested adding a The value assigned to this field could either be a string or an array of strings that resolve to files exporting a Nuxt config: // nuxt.config.js
export default {
// String value resolving to "some-nuxt-preset" module exporting a Nuxt config
extends: "some-nuxt-preset"
// Can also be an array of strings, merging these presets in order
extends: [
"some-nuxt-preset",
"another-nuxt-package/config"
]
} |
|
@wagerfield I like the |
|
@manniL Almost right . :) Which could also have been just the
export default (config) => {
return {
locale: 'en-US'
};
}
export default ({env}) => {
// We can use env in here, to generate the config of head
}This way we might also be able to determine the order by the destructuring parameter (like dependencies). But this might be overkill. Also possible for modules and their options. But here is the order somewhat more important. So you will need a export default ({env}, load) => {
return [
'@nuxtjs/sentry',
[
'@nuxtjs/axios',
load('~/config/modules/axios')
]
]
}There could be a second parameter which takes care of the loading, which just calls the default export with the current configuration as parameter. Similair to plugins. I think this is easier for new Nuxt.js users than the |
|
Plus loading order, we can support Unix style config naming to specify priority be prefixing with numbers. Like |
|
@pi0 Actually I think it might also be possible to dynamically determine the order using a Proxy. Something like this: function makeProxy(config) {
return new Proxy({}, {
get: function(obj, prop) {
if (prop in obj) {
return obj[prop];
} else {
console.log('Load: ' + prop);
return obj[prop] = loadConfiguration(prop);
}
}
});
}
var configuration = makeProxy({});
function loadConfiguration(prop) {
return require('~config/' + prop)(configuration);
}Of course you'd need to watch out and warn for circular deps. |
|
I made a Nuxt module to demonstrate a working POC of dynamic load order of the config files I suggested using a Proxy: https://github.com/Timkor/nuxt-config I am curious what you guys think, and if it is a possibility to add this functionality to nuxt. nuxt-configNuxt Module for splitting your nuxt.config.js into multiple files. Features
Examples:
// Support for object
export default {
quickBuild: true,
sentryDSN: '...'
}
// Support for function:
// Because of {env} this module will first import ~/config/env.js
export default ({env}) => {
return {
hardSource: env.quickBuild,
extend(config, ctx) {
}
}
}
// Support for Arrays
export default [
'~/plugins/google-analytics.js'
]Known issuesThere is still one problem: circulair dependencies. If you would have two config functions:
export default (config) => {
// Read bar
const bar = config.bar; // This will trigger to import ~/config/bar.js
}
export default (config) => {
// Read foo
const foo = config.foo; // This will trigger to import ~/config/foo.js
}This is not possible. So what happens now is:
What needs to be done:The circulair dependency warning is now: It would be nice to have a descriptive warning which tells:
An example of a better warning can be: This can also occur with a path which is larger than 2, for instance: This can be achieved by implementing a dependency tree. |
|
Hi @Timkor Thank you so much for investigating in it and creating a module 👍 Actually, I am trying to understand the use case of exporting a method and receiving the Actually, for Would like some feedback from @nuxt/core-team |
|
@Atinux I thought it would be nice to somewhere have a definition of the environment variables for better IDE support and better TypeScript integration. In addition, I could think of some use cases where you would want some configuration file dependant on some other properties of the nuxt.config.js. However, those use cases could be solved one way or another. Edit: Generating a sitemap with localisation with the following modules: It would be nice to filter the sitemap routes based on properties of localisation (deferred from Then one would need access to the // nuxt.config.js
// Filter routes by language
{
sitemap: {
filter ({ routes, options }) {
if (options.hostname === 'example.com') {
return routes.filter(route => getNuxtI18nLocaleOf(route) === 'en')
}
return routes.filter(route => getNuxtI18nLocaleOf(route) === 'fr')
}
}
}Just an example. Could be written as: // config/sitemap.js
// Filter routes by language
export default ({i18n}) => {
function getNuxtI18nLocaleOf(route) {
// Use i18n here to determine locale of route
return ...
}
return {
filter ({ routes, options }) {
if (options.hostname === 'example.com') {
return routes.filter(route => getNuxtI18nLocaleOf(route) === 'en')
}
return routes.filter(route => getNuxtI18nLocaleOf(route) === 'fr')
}
}
} |
This module seems to solve the problem with several sites in a single instance because most of the module options are configured in nuxt.config.js, but for several sites, there is a strong dependency on the host (postponed from req.headers.host ) that the site will be served, so there are few examples for multi-sites that has different settings. |
|
Hi guys, is this RFC still alive? |
|
Here is a quick recap of Nuxt 3 latest config improvements in relate to this RFC:
Ideas welcome to both nuxt/framework and unjs/c12 repos. |
Objectives:
options.jsnuxt.configvalidation (Both type and keys) and IDE autocomplete.nuxtdir (The Initial version made by @clarkdo but currently disabled). This is essential for improving the size of nuxt serverless builds.Related: nuxt/nuxt#3985
The text was updated successfully, but these errors were encountered: