- What is Jigsaw and how does it use Laravel's Blade?
- Jigsaw is a static site generator that compiles Blade templates and Markdown content into a directory of plain HTML, CSS, and JavaScript. It borrows Laravel's Blade templating syntax, so layouts, partials, components, and directives feel immediately familiar to any Laravel developer. The key distinction is that Jigsaw is a build-time compiler, not a runtime package: it does not hook into a host application's HTTP kernel, Eloquent, queues, or service container. You get Laravel-style authoring ergonomics while shipping a site that needs no PHP server or database in production.
- How do I install Jigsaw?
- Jigsaw is installed as a standalone Composer project rather than as a library you require into an existing app. The canonical command is composer create-project tightenco/jigsaw, which scaffolds a project with config.php, a sources directory, and an asset pipeline. You will also need Node available for the front-end build, which uses Laravel Mix or Vite depending on the Jigsaw release. Once scaffolded, jigsaw serve gives you a local preview with live rebuilds.
- Does Jigsaw need a database or a server in production?
- No. Jigsaw outputs a static artifact, so production hosting is just file serving behind a CDN such as S3 with CloudFront, Netlify, or GitHub Pages. There is no database, no PHP runtime, and no application server to patch or scale. This small blast radius is one of Jigsaw's main advantages: a broken build cannot take down your Laravel application. The tradeoff is that anything requiring server-side execution, such as forms, authenticated content, or personalization, must be handled by an external service or a separate dynamic endpoint.
- Which PHP and Laravel versions does Jigsaw support?
- Jigsaw requires PHP 8.x and Composer, plus Node for the asset pipeline. It pins its own illuminate/* dependencies and its own Node toolchain, which means its version matrix is independent of whatever Laravel version your application runs. That independence is convenient at install time but means Jigsaw upgrades will not automatically land in lockstep with your app's Laravel upgrades. Check the repository's composer.json and release notes for the exact supported versions before pinning it in CI.
- Can I use Jigsaw inside an existing Laravel application and share Blade components?
- Not at runtime. Jigsaw is best treated as a sibling repository that happens to speak the same template language, rather than a module of your Laravel app. Blade layouts and components can be copy-pasted between the two, but importing them directly requires explicitly extracting a shared Blade component package, which is additional scope. Keep the boundary clear so you do not create two competing component ecosystems by accident.
- How do I build and deploy a Jigsaw site in CI?
- A working pipeline is roughly a day's work: scaffold the project, point CI at ./vendor/bin/jigsaw build production, and publish the resulting build directory to your host of choice. Common targets are S3 with CloudFront, Netlify, or GitHub Pages, all of which just need the emitted static files. Because the output is immutable files, rollbacks are trivial and deploys carry no runtime risk. Do make sure someone owns the pipeline, since a failing deploy at the end of the week is an operational problem rather than a technical one.
- Can I add search, forms, or comments to a Jigsaw site?
- Not with Jigsaw alone, because the output is static. Search requires a third-party or prebuilt index such as Algolia or Pagefind, and forms or comments need an external endpoint or service. Gated content and per-user personalization are effectively out of scope for a purely static build. Each of these is an external dependency or a scope increase, so decide up front whether you need them before committing to the static approach.
- How does content authoring work in Jigsaw?
- Content lives in Markdown files with front matter, organized into collections that you configure in config.php, and rendered through Blade templates. Everything is committed to Git, which means every copy change goes through a pull request and code review. For documentation or campaign landing pages owned by engineers, that is a feature because content is versioned and reviewable. For a marketing team expecting a WYSIWYG editor, it is a real blocker unless you pair Jigsaw with a Git-based CMS or agree on a PR review service level.
- How does Jigsaw compare to Astro or Next.js for static sites?
- Jigsaw's advantage is fit with an existing PHP and Blade skill set: no new template language, clean reuse of your Tailwind and CI standards, and a very low learning curve for Laravel developers. Its disadvantage is ecosystem momentum, since static site mindshare has largely shifted toward Astro and Next. If your design system is componentized in React or Vue and maintained by a frontend team, Astro or Next is the honest recommendation. If your team is PHP-first and the site is documentation or landing pages, Jigsaw is safe and sufficient, though it is table-stakes tooling rather than a differentiating bet.
- Is Jigsaw actively maintained, and what are the ongoing risks?
- Jigsaw is a mature, stable tool from Tighten, so the risks are less about bugs and more about operational drift. You inherit a second PHP dependency graph and a second Node toolchain to patch independently of your Laravel app. There is also a single-owner knowledge risk, since typically only one or two developers understand the config-as-PHP conventions, collections, and front matter. Mitigate by documenting the setup, keeping upgrades on a schedule, and testing builds in CI so a broken toolchain surfaces before deploy day.