feat(cli): programmatically pass nuxt config overrides (to dev)

[dword-design]

🔗 Linked issue

#19347

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Allows to pass additional options to runCommand, so a Nuxt config can be passed programmatically. Resolves #19347. This isn't really a clean solution. Clean would be to have a function with the logic and the command consumes this function. The logic is also exported and someone can use it instead of the command.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly. (there is no doc)

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[pi0]

Generally love the idea (tbh always been thinking to have it). Only there is a concern about --config <path to custom config file> (mapping to configFile from c12) vs --config <config_overrides_object>.

I think we should use --config for passing path to config file.

For object passing, we might use NUXT_CUSTOM_CONFIG env variable revived by destr as it also allows passing custom config from different programmatic conditions with more flexibility. this could be a feature from unjs/c12 btw. to test properly and consistently introduce to CLis. Relavant issues:

• Automatically inject env variables as config unjs/c12#2
• Allow overriding config with environment variables unjs/c12#16
• Allow overridng extends with env unjs/c12#23

[dword-design]

@pi0 I'm not sure if passing the config via environment variables alone will be sufficient since a config can contain functions (e.g. a module imported and passed directly). I think there is no way around passing the config as a JS object directly.

[pi0]

Fair enough. Only since --config as arg should be reserved for config path, i think we can workaround it slightly differently by passing custom options as second argument to the sub-commands (here) unblocking programmatic usage.

[dword-design]

@pi0 yeah I linked a PR that does a similar thing (adding it to args)