/ 
Developer-Dashboard-3.26
/ Developer::Dashboard::Config

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. Matching collector and provider entries merge by logical identity, so deeper layers can override fields such as interval or nested indicator metadata without discarding inherited defaults.

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, the persisted no_editor read-only browser 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. Matching collectors merge by name, so a config entry such as housekeeper can override only interval or indicator while still inheriting the built-in collector code and cwd.

WHAT USES IT

It is used by init flows, path alias commands, auth/session bootstrap, collector refresh, web server settings, 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.