- How do I install Gitdown in a Laravel application?
- Run composer require calebporzio/gitdown and start calling it, because there is no service provider, facade, published config, or asset pipeline to register. Since the package has been archived since 2019, treat installation as unproven until you have rendered real content on your target PHP version in CI, not just on a laptop. If the pinned cebe/markdown constraint fails to resolve against PHP 8.2+ or Laravel 10/11/12, that constraint is the blocker rather than the Gitdown API itself. Outside Laravel the same install works in Symfony or vanilla PHP, because the public surface is effectively a single static call.
- Does Gitdown support GitHub-flavored Markdown features such as tables, fenced code blocks, and task lists?
- Yes, Gitdown delegates to cebe/markdown's GithubMarkdown::parse(), which covers the core GFM set including tables, fenced code blocks, strikethrough, autolinks, and task list syntax. What it does not cover is anything GitHub added after 2019, so there are no footnotes and no > [!NOTE] style alert blocks, plus edge-case differences in table parsing and autolink behavior. Spike a handful of real documents containing tables and fences before you commit to it.
- Is Gitdown safe for rendering untrusted Markdown such as comments, support tickets, or AI-generated output?
- No, not on its own. GFM permits raw inline and block HTML and the parser passes it through by specification, so any untrusted path without an allowlist sanitizer is an XSS incident waiting to happen. If any rendering path is fed by user input, pasted text, or model output, sanitization is non-negotiable and should be scheduled now rather than deferred.
- Does Gitdown work with Laravel 10, 11, and 12 on PHP 8.2 or newer?
- Conditionally. The package itself installs trivially in isolation, but its 2019-era pinned cebe/markdown constraint is what has to resolve against a modern PHP and Laravel tree. Run a short spike: composer require, render tables and fences, and confirm it resolves in CI on your exact versions rather than only on a laptop. Expect deprecation notices on PHP 8.2+ that can become exceptions under strict error handling.
- Is Gitdown still maintained, and what are the risks of depending on it?
- No. The repository has been archived since 2019, has roughly 217 stars, no recorded dependents, no security process, and no semver signal for behavioral drift. The dominant risk is abandonment rather than capability, with the practical fallout being GFM drift, PHP 8.2+ deprecation noise, and stale transitive constraints that can block a future Laravel major. If you adopt it, pin exact versions, commit the lock file, and name an owner with a migration ticket and a date.
- What should I use instead of Gitdown, and how hard is switching?
- The natural target is league/commonmark with its GFM extension, or spatie/laravel-markdown if you want Blade components and syntax highlighting wrapped around it. Migration is cheap precisely because Gitdown is thin: implement the same interface against the new engine, rebind it, and diff HTML output over a corpus of real content. For most products the swap is an afternoon of work.
- How should I structure my Laravel code so Gitdown is easy to replace later?
- Define an application-owned contract such as MarkdownRenderer, write a GitDownRenderer adapter that implements it, and bind it in a service provider on day one. No controller, Blade view, console command, or job should ever name the package directly. That hour of indirection turns every future migration from N tickets into a single one.
- Is Gitdown a Git command wrapper or a Markdown-to-HTML renderer?
- The shipped code is a Markdown parser wrapper, effectively one static call delegating to cebe/markdown's GithubMarkdown::parse(). Some package descriptions carry a stale narrative about running Git commands or turning GitHub Issues into a blog, and that narrative does not match the delivered source. Verify against the repository itself before you build a requirement around either story.
- How do I test that switching Markdown renderers won't break my output?
- Build a golden-file corpus of real content your application actually renders, run both the old and new renderer over it in shadow mode, and diff the resulting HTML. Quantify the divergences rather than guessing, then decide whether any of them matter to the product. This lets the output differences, rather than the dependency's reputation, drive the migration decision.
- Does Gitdown need network access or a GitHub API token to render Markdown?
- No. Parsing is local and deterministic, so there is no API call, no token, and no GitHub dependency at render time. A quick way to prove it is to re-run your rendering test with network access and GITHUB_TOKEN unset and confirm the output is identical. That also confirms the GitHub Issues as a blog description is not describing real behavior.