Discussion draft: ConfigProvider to help with drop-ins.#300
Draft
Discussion draft: ConfigProvider to help with drop-ins.#300
ConfigProvider to help with drop-ins.#300Conversation
added 5 commits
February 9, 2026 21:29
- doc/discovery/config-sourcing.md: Complete analysis of c12's configuration pipeline, showing how defu merges configs from multiple sources with mermaid diagrams - doc/discovery/dynamic-configs.md: Exploration of dynamic configuration sources including drop-in directories, provider pattern design, and layering provenance
Refactors c12's config loading to use a provider-based architecture: - Add ConfigProvider interface with name, priority, and load() method - Built-in providers: overrides, main, rc, packageJson, defaultConfig - Providers sorted by priority (lower = higher precedence) - New options.providers allows custom/replacement providers - Providers can access previously loaded configs via context - Backward compatible: loadConfig() works unchanged without providers - Exports: getDefaultProviders, sortProviders, create*Provider helpers This enables users to: - Inject custom config sources (env vars, remote config, vault) - Reorder or remove default sources - Build configs that depend on other loaded configs
Add comprehensive documentation for the implemented provider system: - Architecture overview with mermaid diagram - Core types (ConfigProvider, ProviderContext, ProviderResult) - Built-in providers table - Usage examples (custom, replacing, reordering, dependencies, remote) - How the provider system works (step-by-step) - Impact on existing c12 users (zero breaking changes) - Minor differences noted (error message path resolution) - Future enhancements roadmap - Files changed summary
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Used Opus to try to work on something for #298. This takes the bespokely purposefully built
loader.tsand creates aConfigProviderthat each configuration type provides. It then runs each ConfigProvider to produce the output.The work here is deeply impactful to the architecture and needs much more attention & regard. It is provided now as an early draft, and as a baseline to show how drop-in might work, which is a further stacked draft-PR (to follow very shortly).
This draft is 1 of 2 PRs that could be done to implement drop-in config. rektide#1 shows the remainder of the work, with an implementation of a
ConfigProviderthat can doconfigDir. Also note: merging this PR would expose aprovidersoption that I could use to implement drop-in configuration in my own library or app, without needing to add that code directly intoc12.Questions
ConfigProvider#loadis the only capability of a ConfigProvider right now. What if anything might we provide to supportwatchConfigtoo; provide a list of paths we want watched? There's nothing done formagicastsupport in this PR either; would we want some kind ofupdateConfigsupport in this PR?