Macdom Laravel Package

Product Decisions This Supports

• Template-engine selection for HTML-first teams. Macdom lets authors define custom HTML tags/macros so designers can build components in markup they already know, rather than learning Blade or Twig directives. The PM decision this informs is whether to optimize templating for designer velocity versus framework convention.
• Prototyping and design-to-code handoff. For internal tools, style guides, or marketing microsites, it lowers the barrier for non-PHP contributors to assemble pages, shortening the loop between design and a shippable artifact.
• Build vs. buy vs. vendor. With a permissive BSD-3-Clause license, the real decision isn't "adopt or not" but "consume upstream, fork, or reimplement the pattern in-house." Macdom is a useful reference implementation of the custom-HTML-tag DSL concept even if you never ship it.
• Static/standalone content generation. It runs as a preprocessor with no runtime dependency in the output, which supports decisions about generating static marketing pages or documentation without introducing a JS framework.
• Legacy modernization sequencing. Where an existing PHP 5/7 product already uses this style of preprocessing, the PM decision is whether to freeze, fork, or schedule migration — not whether to standardize on it.
• Component-library ownership. It informs whether the product team maintains its own templating layer (control, but maintenance burden) or delegates to the framework's engine (less control, more support).

When to Consider This Package

Consider it when:

• You are on a legacy PHP 5.6/7.x stack where modern template engines aren't viable without an upgrade project.
• Your authors are HTML-literate and PHP-shy, and the cost of teaching Blade/Twig is the actual bottleneck.
• The output is static or low-risk (marketing pages, internal tools, documentation) where a templating bug is a cosmetic issue, not a security or revenue event.
• You are willing to vendor or fork the code and own it — the BSD-3-Clause license makes this legally straightforward.
• You need a small conceptual reference for a custom-tag DSL you intend to build internally.

Look elsewhere when:

• You are building on Laravel or Symfony. Blade and Twig are first-party, documented, tested, and staffed by the community; introducing a second engine creates two mental models for one codebase.
• You require PHP 8.x compatibility, ongoing security patching, or any vendor support expectation. The last release was October 2017; assume no maintenance and validate compatibility yourself.
• The surface is security-sensitive (auth flows, admin panels, anything rendering untrusted input) — an unmaintained preprocessor is an unpatched attack surface.
• You need ecosystem depth: IDE support, Stack Overflow answers, hiring pools, or third-party extensions. At ~11 stars, there is effectively no community to lean on.
• Onboarding or bus-factor risk matters. A single-maintainer 2017 package is a knowledge silo.

How to Pitch It (Stakeholders)

For executives (one paragraph): Macdom is a lightweight, permissively licensed HTML preprocessor that lets designers build page components using plain HTML tags instead of learning a templating language. The upside is faster design-to-code turnaround and zero runtime footprint in the shipped output. The downside is material: the project has had no release since 2017, has a negligible community, and carries no compatibility or security guarantees. My recommendation is not to adopt it as a new dependency in any product we intend to support. Its value to us is as a reference pattern for HTML-first authoring, or as a vendored component in a bounded, low-risk context where we explicitly accept ownership of the code. Adopting it broadly would trade a small short-term velocity gain for a long-term maintenance liability.

For engineering (summary): Small, self-contained PHP preprocessor implementing custom HTML tags, macros, and includes — no runtime dependency in output. BSD-3-Clause permits forking and internal redistribution. Key risks: no releases since 2017, no confirmed PHP 8 support, minimal test/CI signal, single-maintainer bus factor, and no community review of edge cases. If we proceed, scope it to non-critical surfaces, vendor the source into our repo, pin and document the fork, and add our own test coverage around the specific tags we use. Otherwise, standardize on Blade/Twig and use Macdom only as design inspiration.