Highlightjs Laravel Package

Product Decisions This Supports

• Feature delivery for code-centric UI: enabling syntax highlighting in developer docs, admin panels, markdown/CI log viewers, or user-generated code snippets without standing up a separate frontend asset pipeline.
• Build vs. buy on asset management: a Composer-installed shim lets a Laravel team treat a JS dependency as a PHP dependency, which is a defensible shortcut when the team has no npm/Vite ownership model, but it is a buy decision on the packaging, not on Highlight.js itself.
• Roadmap sequencing for documentation and internal tooling: if self-serve docs, changelog rendering, or a snippet-sharing feature is on the near-term roadmap, this unblocks a thin slice quickly; it is not a platform investment.
• Vendor and licensing risk intake: the NOASSERTION license tag and a low health score (1.38 with ~102 stars) mean this belongs in a dependency-review decision, not a silent composer require. It informs whether legal/security sign-off is a launch gate.
• Offline/air-gapped delivery: for on-prem or regulated deployments where CDN fetches and npm registries are blocked, a Composer-shipped asset can be the simplest path to deterministic, reproducible installs.
• Deprecation planning: adopting it as a transitional shim is a legitimate decision if the exit path (swap to official npm package or self-hosted bundle) is documented in the same ticket.

When to Consider This Package

Consider it when:

• Your application already governs frontend assets through Composer and you have no Vite/npm build step, and adding one is out of scope for the current cycle.
• You need a pinned, vendored copy of Highlight.js for offline or air-gapped deployment, and reproducibility matters more than freshness.
• The usage is genuinely thin — highlighting a handful of languages in an internal tool, a docs page, or an admin-only code viewer.
• You can tolerate the asset being pinned and manually bumped; nobody expects this shim to track upstream releases on your behalf.
• License and provenance have been reviewed and cleared (the NOASSERTION tag must be resolved with the actual upstream Highlight.js license before merge).

Look elsewhere when:

• You already run Vite, Webpack, or any npm-based pipeline — adding a Composer shim creates a second, competing source of truth for the same asset. Use the official highlight.js package.
• You need active maintenance, timely security patches, or upstream parity — a 1.38 health score and "shim repository" description are explicit signals that this is packaging, not stewardship.
• You need custom language bundles, tree-shaken builds, or theme tooling; a shim generally ships a fixed artifact.
• Your content is untrusted user input rendered at scale — highlighting is a client-side concern you want to control and update independently of PHP deploys.
• Your organization requires an auditable, actively maintained dependency for anything user-facing; treat this as internal-tooling-only scope.
• Licensing cannot be confirmed. NOASSERTION is a blocker, not a note.

Adoption guardrails if you proceed: pin the version explicitly, record the upstream Highlight.js version it wraps, isolate the import behind a single view component or Blade partial so a future swap is a one-file change, and set a calendar reminder to re-evaluate against the official distribution each major release cycle.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost packaging convenience that lets us add code syntax highlighting to [docs/admin/tooling] using the dependency system we already have, avoiding a new frontend build pipeline and its associated headcount and CI cost. It is not a strategic platform choice — it is a shim around a well-known open-source library, and we should treat it as temporary scaffolding with a documented exit path. Two caveats need sign-off before we ship: the license is currently unasserted and must be verified, and the project shows low maintenance activity, so we will pin the version and own upgrades ourselves. Expected scope is a few days of work and no ongoing infrastructure; the risk is bounded and reversible.

To engineering: We're proposing the Composer shim for Highlight.js rather than standing up npm/Vite for this slice. Concretely: it keeps asset delivery inside our existing install story, works offline, and is reproducible. The trade-off is explicit — we get a pinned artifact, not upstream tracking, so security patches are our responsibility and upgrades are manual. Constrain the blast radius: wrap it in one Blade component or view partial, pin the version in composer.json, and do not let a second code path import it directly. If anyone is already planning a frontend build pipeline this quarter, say so now — that changes the recommendation to the official package. Also flag: license reads NOASSERTION, so please confirm the wrapped Highlight.js license before this merges.