/ 
Developer-Dashboard-3.61
/ Developer::Dashboard::File

NAME

Developer::Dashboard::File - older file compatibility wrapper

SYNOPSIS

Developer::Dashboard::File->configure(aliases => { output => '/tmp/output.txt' });
my $file = Developer::Dashboard::File->output;
my $notes = Developer::Dashboard::File->resolve('notes');
my $name = 123;
my $numeric = Developer::Dashboard::File->$name();
Developer::Dashboard::File->write(output => "ok\n");

DESCRIPTION

This module exposes a project-neutral compatibility layer for older bookmark code that expects a File package.

METHODS

resolve

Returns the resolved file path for one configured alias or literal path without reading file content.

METHODS

configure, all, exists, read, cat, write, touch, rm

Configure and resolve compatibility files.

PURPOSE

This module provides named file resolution for runtime files and configured aliases. It gives callers the same conceptual file names exposed by dashboard files and dashboard file list without forcing them to know the exact on-disk layout under the current runtime.

WHY IT EXISTS

It exists so code and bookmark snippets can refer to stable file concepts such as global_config, dashboard_log, or configured aliases instead of hard-coding file paths. That keeps file-aware code portable across home and project-local runtimes.

WHEN TO USE

Use this file when a module, bookmark, or helper needs a named runtime file and should not know whether the active file path came from the home runtime, a project override, or a user-defined alias.

HOW TO USE

Load Developer::Dashboard::File and ask it for the named file you need. Use it as the semantic file layer above the lower-level file registry instead of hard-coding ~/.developer-dashboard descendants.

When you need the complete resolved file payload that dashboard files prints, call Developer::Dashboard::File->all. It returns the same hash shape as the CLI command.

WHAT USES IT

It is used by bookmark/runtime helper code, by compatibility tests, and by contributors who need the older top-level File abstraction to resolve through the current layered runtime.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::File -e 1

Do a direct compile-and-load check against the module from a source checkout.

Example 2:

prove -lv t/07-core-units.t t/21-refactor-coverage.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.