/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::Folder

NAME

Developer::Dashboard::Folder - older folder compatibility wrapper

SYNOPSIS

Developer::Dashboard::Folder->configure(paths => $paths, aliases => { postman => '/tmp/postman' });
my $dir = Developer::Dashboard::Folder->postman;

DESCRIPTION

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

METHODS

configure, home, tmp, dd, bookmarks, configs, cd, ls, locate

Configure and resolve compatibility folders.

PURPOSE

This module provides named folder resolution for runtime roots and configured aliases. It gives callers the same conceptual folder names exposed by dashboard paths 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 folder concepts such as runtime, dashboards, or configured aliases instead of hard-coding layout paths. That keeps folder-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 directory and should not know whether the active path came from the home runtime, a project override, or a user-defined alias.

HOW TO USE

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

WHAT USES IT

It is used by bookmark/runtime helper code, by prompt and file operations that want named folder resolution, and by tests that keep alias and runtime-root behavior consistent.

EXAMPLES

Example 1:

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

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

Example 2:

prove -lv t/21-refactor-coverage.t t/00-load.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.