Skip to content

Add support for a version-controlled assets/ directory #64

Description

@jmacdotorg

Summary

Add an assets/ directory whose contents are copied into docroot/ on publish. This lets authors keep source assets under version control while keeping the generated docroot/ out of it — today the two are forced to live together, since hand-placed images and other static files go straight into the generated output directory.

This feature was proposed and substantially implemented by @danbarbarito in #30 (2018). The feature is still wanted; that PR predates significant internal changes (1.900) and needs rework, so we're capturing the design here and using the PR as a starting point. Thanks to @danbarbarito for the original work and rationale.

Rationale (from #30)

The only reason I made this change is because I would prefer to keep the docroot out of version control, but my static files in version control. This change allows you to keep your static files separate from your generated files.

Design sketch

  • New asset_path config key + asset_directory lazy-built attribute, derived via _build_subdirectory like the other dirs (source, templates, etc.).
  • Plerd::Init scaffolds an assets/ subdir and documents asset_path in the sample config.
  • On publish, copy the tree under assets/ into docroot/, preserving subdirectory structure.

Work needed beyond #30

  1. Atomic copying. As of 1.900 all publication writes are atomic (render to a temp file in the target dir, then rename() into place) so a web server never sees a half-written file. Asset copying must follow the same pattern rather than copying directly into docroot/.
  2. Incremental-publishing behavior. 1.900 made plerdwatcher republish incrementally via publish_file, so publish_all is no longer the only path. Decide and implement how assets fit: copy only on full publish_all, have the daemon watch the assets dir, or defer — needs a deliberate choice.
  3. Simpler implementation. The original used manual File::Find + substr/split path math. Plerd already depends on Path::Class; prefer its directory traversal/path handling (or a single well-chosen CPAN module) over hand-rolled string slicing.
  4. Real tests. The Add ability to have static assets #30 diff only wires asset_path into the test config. Add tests to t/basic.t that place file(s) in an asset directory, publish, and assert they land in docroot/ with the correct relative paths.

Prior art

PR #30 has a working first cut (asset_path attribute, publish_assets/_publish_asset, Init.pm scaffolding) that's a useful reference for the rebuild.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions