feat: export default config

[ferferga]

Description

Makes the default config consumable by the user.

Use case

I'm developing a plugin that needs to access the build.outDir variable:

config: (conf) => {
    return {
      build: {
        rollupOptions: {
          plugins: [
            AnotherPlugin({
              outDir: conf.build.outDir,
            })
          ]
        }
      }
    };

However, conf.build.outDir variable is only defined if the user has provided that option in their own configuration file. If not, it will only be accessible on the configResolved hook, which makes our use case useless.

With this PR, we can make a graceful fallback:

config: (conf) => {
    return {
      build: {
        rollupOptions: {
          plugins: [
            AnotherPlugin({
              outDir: conf.build.outDir ?? configDefaults.build.outDir,
            })
          ]
        }
      }
    };

[ferferga]

I have no idea what's wrong with the CJS build, I don't see where side effects are being introduced that pkg is required... 😅

[sapphi-red]

Recently we considered exposing the default config values, but didn't do it, because we were not sure how to expose them in a intuitive way.
#18550 (comment)
We need to solve this to expose the default values. Any suggestions are welcome 🙂.

[ferferga]

@sapphi-red (if you want me to continue the discussion in the original place, please let me know)
What do you think it's exactly "unintuitive" with exposing the defuault object? In my opinion, it's as straightforward as it gets. If I want to just get a value of the default config (like in my posted example, it's much simpler (and faster) to do configDefaults.build.outDir instead of mergeWithDefaults({}).build.outDir.

Also, as an FYI, after diving into Vite's source code, I wanted (for another PR) to change the way the defaults are accessed: I believe they should be factory functions instead, so we always get copies of them and utils like deepClone will not be needed.

[sapphi-red]

What do you think it's exactly "unintuitive" with exposing the defuault object?

build.outDir is one of the non-problematic ones. The problematic ones are, for example, build.cssMinify, resolve.conditions:

• build.cssMinify: defaults to 'esbuild' for SSR and build.minify for non-SSR builds
• resolve.conditions: defaults to DEFAULT_CLIENT_CONDITIONS for non-SSR and ssr.target: 'webworker', otherwise DEFAULT_SERVER_CONDITIONS

What should be set for these options?

[ferferga]

@sapphi-red Oh I see what you mean now, thanks!

Wouldn't a function returning an object, like I suggested in my previous comment, solve exactly this? It could have a ssr?: boolean type signature for its parameters. Even I would say the mode can be inferred by the function directly thanks to closures?

[sapphi-red]

Wouldn't a function returning an object, like I suggested in my previous comment, solve exactly this? It could have a ssr?: boolean type signature for its parameters. Even I would say the mode can be inferred by the function directly thanks to closures?

Maybe it would work if the parameter doesn't get huge. I haven't looked if ssr is the only one needed.

[bluwy]

I'm going to close this for now as there's still questions about how the configs should be exposed, especially conditional ones. If this is still needed, it'd be best to open a new issue to discuss it.