Js Transformer Filter Laravel Package

Product Decisions This Supports

• Feature scoping: "author JavaScript inside Pug" — whether in-template JS/TS/JSX blocks are a supported authoring path. This package only earns its place if the answer is yes and the transform must happen during Phug compilation.
• Build vs. buy (really: buy vs. write 80–150 lines) — the package is a thin adapter between Phug's filter interface and the js-transformer family. The make/buy comparison is not against a vendor contract; it's against a self-authored filter. With 4 stars and 0 dependents, self-authoring is a credible option, not a fallback.
• Toolchain consolidation roadmap — it supports a decision to keep JS transformation in the template layer (Phug compile step) versus the standard asset pipeline (Vite/Webpack/esbuild/tsc). Choosing this package means committing to two transform paths, which affects cache invalidation, source maps, and failure modes.
• Legacy migration sequencing — a legitimate use case is a Phug-rendering product that already emits inline scripts from templates and needs a per-block transform hook during an incremental migration. Here the package is a bridge, not a destination.
• Dependency risk policy — pins it as a "pilot-tier" dependency: single-maintainer ecosystem, tiny adoption surface, MIT. Decision is whether to depend directly, vendor, or wrap internally, and whether it's allowed on the critical render path.
• Use cases that genuinely fit — static site generators built on Phug, internal admin/email templating tools, and component-co-located Pug authors. It does not fit request-time rendering without a hard compile-time cache.

When to Consider This Package

Consider it when:

• You are already on Phug for server-side template rendering and need JS/TS/JSX blocks processed at compile time — the filter has no value outside Phug.
• You want one generic filter across multiple transformer backends rather than a bespoke filter per tool (Babel, TypeScript, etc.).
• The js-transformer family is already in your dependency graph, so this is a small delta rather than a new sub-tree.
• Transform runs at build/compile time, and you can pin a version, lock it, and own the test coverage yourself.
• Your team accepts low-adoption MIT dependencies with effectively zero community stress testing (0 dependents) as a normal internal-tooling tradeoff.

Look elsewhere when:

• You are not using Phug — use the underlying js-transformer package directly; this filter adds nothing.
• Your pipeline already has Vite/Webpack/esbuild/tsc. Double-transforming at template render adds a second toolchain, source-map ambiguity, and render-time failure modes for no user-visible gain.
• You need type checking — transformers strip types; they do not check them. Pair with tsc or don't adopt.
• You need support guarantees, security review depth, or long-term maintenance commitments. No dependents means no downstream validation; a ~100-line in-house filter is likely the lower-risk path.
• Transform would run per request. Server-side JS transform is fine at compile time and catastrophic on the hot path; if your caching story isn't solid, this is disqualified.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed adapter that lets our PHP Pug templates compile modern JavaScript inline during template build. Cost to trial is low and cost to abandon is low. Adoption signals are weak — 4 stars, 0 dependents, one maintainer ecosystem — so treat it as internal convenience, not a strategic dependency. Recommendation: pilot on a single legacy template surface, not platform-wide, and do not let it onto the request path.

Engineering: It is the generic Phug filter over the js-transformer family: wire a transformer (Babel, TypeScript) and get transform blocks inside Pug during compilation. The package ships only the adapter — all real risk lives in the transformer backend and in your build cache. The Phug filter interface is narrow, so self-implementing is realistic if you want to avoid the dependency. Adopt only if Phug and js-transformer are already in the tree; otherwise vendor a small filter, pin it, run transforms strictly at build/compile time, and pair with tsc for any type safety.