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.