- How do I install the Tighten Jigsaw docs template?
- Use composer create-project tightenco/jigsaw-docs-template to scaffold a new documentation site, or clone the repository and re-root it as your own project. It is a starter scaffold rather than a dependency, so it is never added with composer require. Once scaffolded, you run the standard Jigsaw and Vite build commands to produce the static output.
- Can I install this package with composer require?
- No. tightenco/jigsaw-docs-template is a starter scaffold, not a consumable library, so composer require is the wrong workflow. Adopt it with composer create-project or clone and re-root it, then commit the result as your own project. That is also why the low star count and zero dependents are normal for a docs template rather than a warning sign.
- What PHP and Node versions do I need to build the docs site?
- The build requires PHP 8.x with Composer plus a Node toolchain, because the template ships a Vite-based asset pipeline alongside Blade and Tailwind. Recent releases bumped vite, rollup, picomatch, and tar, so check the pinned versions in package.json before committing. If your CI image already carries both runtimes you are set; otherwise budget time for a new build image.
- Does this template work with Laravel?
- Jigsaw is built by Tighten and compiles Markdown plus Blade into static HTML, so you reuse the Blade partials, front matter, and config.php collections that Laravel developers already know. It does not run inside a Laravel application and needs no application server, database, or auth surface. That makes it a natural fit for a PHP and Blade fluent team, even though Laravel itself is not a dependency.
- Where can I host the generated documentation site?
- The deliverable is a plain folder of static files, so it drops unmodified into GitHub Pages, S3 with CloudFront, Netlify, Cloudflare Pages, or an internal nginx server. There is no runtime to patch and no server-side surface to secure. That portability is one of the strongest reasons to use it for internal documentation.
- Does the template include full-text search, versioned docs, or i18n?
- No. It ships layouts, styling, navigation, and content structure, but there is no built-in full-text search, no versioned documentation, no i18n, and no generated API references. Search is the most common gap and the most common reason teams fork the template and then stall. Retrofitting these features usually means integrating Algolia DocSearch or Pagefind and erasing much of the upfront cost advantage that justified adoption.
- How does it compare to Docusaurus, Astro Starlight, VitePress, or MkDocs Material?
- Those projects already ship search, versioning, and i18n, so a Node, Python, or Go team gains little by adding PHP and Composer just to render Markdown. The Jigsaw template makes sense when your team is already PHP and Blade fluent and the target is a straightforward static docs site. For everyone else, staying in an ecosystem you already maintain is usually the better trade.
- Is the Jigsaw docs template actively maintained?
- Recent releases are largely Dependabot bumps, which is passive hygiene rather than active feature development. Upstream will not absorb your feature requests after you fork, and there is no supported upgrade path for the template itself. Name someone accountable for cherry-picking upstream changes each quarter, or expect the fork to drift within a quarter.
- How much work is customizing the layout, branding, and navigation?
- Layout, navigation, and theming live in Blade components plus the Tailwind configuration, so rebranding means editing templates and tailwind.config.js rather than flipping options. Estimate the real cost by counting how much navigation and layout logic you would rewrite for your own information architecture. If that count is high, treat the template as raw material rather than an adopt-as-is solution.
- Is this template safe to run in production?
- The risk profile is low severity but high ambiguity, which suits a timeboxed pilot better than a customer-critical revenue surface. Dependency exposure is build-time only, so a compromised dev dependency does not reach the static artifacts you deploy, and there is no server runtime to patch. The lasting production concern is divergence, since fork-and-own means no supported upgrade path.