NAME
Developer::Dashboard::Config - merged configuration loader
SYNOPSIS
my $config = Developer::Dashboard::Config->new(files => $files, paths => $paths);
my $merged = $config->merged;
DESCRIPTION
This module loads and merges global and repo-local configuration for Developer Dashboard.
METHODS
new, load_global, save_global, load_repo, merged, collectors, path_aliases, global_path_aliases, web_workers, save_global_web_workers, web_settings, save_global_web_settings, save_global_path_alias, remove_global_path_alias, docker_config, providers
Load and expose configuration domains used by the runtime.
The web_settings() and save_global_web_settings() methods manage web service settings including host, port, workers, ssl flag, and optional ssl_subject_alt_names entries used to extend the generated HTTPS certificate. These settings persist across restart, so dashboard restart inherits the previous serve session configuration.
PURPOSE
This module owns runtime configuration files such as config/config.json, path aliases, web settings, collector definitions, and feature-specific config trees. It loads the effective config through DD-OOP-LAYERS and writes changes back to the deepest participating runtime root.
WHY IT EXISTS
It exists because configuration has to obey the same layered runtime rules as pages, hooks, and state. Centralizing config lookup and writes prevents commands from accidentally ignoring project-local overrides or overwriting the wrong runtime layer.
WHEN TO USE
Use this file when changing config schema defaults, alias persistence, collector definitions from config, or any feature that reads or writes under config/ in the runtime tree.
HOW TO USE
Construct it with the file registry and path registry, then use the accessor and persistence methods instead of reading config JSON directly. New config-backed features should register their data under the appropriate runtime config directory and let this module handle loading rules.
WHAT USES IT
It is used by init flows, path alias commands, auth/session bootstrap, collector refresh, web server settings, api-dashboard/sql-dashboard config storage, and release/integration tests that verify runtime config behavior.
EXAMPLES
Example 1:
perl -Ilib -MDeveloper::Dashboard::Config -e 1
Do a direct compile-and-load check against the module from a source checkout.
Example 2:
prove -lv t/06-env-overrides.t t/18-web-service-config.t
Run the focused regression tests that most directly exercise this module's behavior.
Example 3:
HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t
Recheck the module under the repository coverage gate rather than relying on a load-only probe.
Example 4:
prove -lr t
Put any module-level change back through the entire repository suite before release.