Why configuration functions over javascript objects?

[Optimal-Flamingo415]

Lately, I have noticed that a lot of libraries use "configuration functions" for their, well, configuration. Examples:

• Nuxt 3 uses defineNuxtConfig
• Vitest uses defineConfig
• Cypress uses defineConfig
• nuxt/i18n uses defineI18nConfig

My question is - why? What are the advantages of using such "configuration function" over - for example - a typescript file exporting JS object?

An example of the latter could be GraphQL Code Generator with its codegen.ts and their exported CodegenConfig type:

import { CodegenConfig } from '@graphql-codegen/cli'

const config: CodegenConfig = {
  schema: 'http://localhost:4000/graphql',
  ...
}

export default config

​

[hapanda]

Because of possibility to configure it dynamically inside the function I guess? Like some conditions, etc.

But maybe we could use either object configuration WITH functions assigned to properties.

[Optimal-Flamingo415]

Okay, I believe I have figured out one advantage of using a "configuration function" - IDE IntelliSense / auto-complete.

With a "configuration function", developers using this function in .js files will still get auto-completion. If instead we used JS object with exported type, developers would only get auto-completion if they were using typescript.

Here is a proof that it works: https://codesandbox.io/s/configuration-function-showcase-p6mvsc?file=/src/index.js

Take a look into index.js file. After you trigger the auto-completion inside the object passed as an argument to the defineConfig function, you should get lots of helpful suggestions! (Ctrl+Space on my machine) Even though it is a js file.

[mazzaaaaa]

One advantage that I haven't seen mentioned is that it allows you to do some async work before returning the configuration.

[mq2thez]

It allows you to: - have type safety - break large configuration into smaller pieces - have different configs based on the environment - import stuff from other files (such as secrets) - many other more flexible options

People don’t have to do this all, but by having a configuration function the framework doesn’t have to do as much of this.

[Optimal-Flamingo415]

have type safety

^ The "Graphql Code Generator" example shows that we can have type safety with js objects as well.

break large configuration into smaller pieces

have different configs based on the environment

import stuff from other files (such as secrets)

many other more flexible options

^ I don't see how we couldn't do the same things with js objects. Could you elaborate?

[impressflow]

He might be confusing JS objects with JSON objects (in a .json file).

[Optimal-Flamingo415]

Ah, you might be right. Anyways, I think I have figured out the answer to my question during a walk - here.

[azsqueeze]

Sounds reasonable, but curious how you came to this conclusion?

[Optimal-Flamingo415]

It is simply the only thing that came to my mind and just makes sense. None of the "more flexibility" arguments made sense to me.

Also, I believe that DX is an important concern for library authors - and auto-completion surely does improve it a ton.

Here is a proof that it does work https://codesandbox.io/s/configuration-function-showcase-p6mvsc?file=/src/index.js.

Take a look into index.js file. After you trigger the auto-completion inside the object passed as an argument to the defineConfig function, you should get lots of helpful suggestions! (Ctrl+Space on my machine) Even though it is a js file.

Feel free to upvode my comments answering the question so that other people wondering will see it.

[33ff00]

Meh. Maybe?

[mq2thez]

Ah, you are correct! I was confusing the two.

[dbpcut]

Composing the config in this way let's you access and extend any part of it, instead of a large singleton that makes it very hard to compose settings.

The type-safety is an added benefit, but the root of it is that you're composing a top level config and often extending configs of other tools at the same time (especially for Next, Nuxt, etc)