LaRecipe: Markdown Documentation Inside a Laravel App

The problem LaRecipe targets: docs that ship with the Laravel app

Most documentation tools assume the docs are a separate artifact. You build them in a static site generator, publish them to a hosting target, and wire a domain or a subpath. LaRecipe takes the opposite position. The README describes it as "a code-driven package that provides an easy way to create beautiful documentation for your product or application directly inside your Laravel app." The documentation is part of the application, not a sibling project.

That framing decides who the package is for. If you maintain a Laravel product and you want API notes, onboarding guides and release notes to be reviewed in the same pull request as the code they describe, the coupling is the feature. If your documentation has a different audience, a different release cadence, or writers who never touch PHP, the coupling is a liability.

The repository is PHP, published as binarytorch/larecipe, and licensed under MIT. The README points to a separate site at larecipe.saleem.dev for the full documentation, and lists official add-on packages for a dark theme, RTL support, feedback collection and Swagger integration. Those add-ons matter to the decision: the core package does not appear to bundle every presentation concern, so plan for at least one extra dependency if you need right-to-left rendering or API reference pages.

How the package is structured: routes, resources and a publishable directory

The repository layout is the clearest statement of the architecture. There is a routes/ directory, which is how the /docs endpoint becomes reachable without the application author writing a route. There is a resources/ directory holding the front-end assets, a stubs/ directory for files the installer copies into the host application, and a publishable/ directory for assets meant to be exported into the consuming app. A mix-manifest.json and webpack.mix.js sit at the root, so the shipped CSS and JavaScript are built with Laravel Mix.

The front-end dependencies listed in package.json tell you what the rendered page is made of: Vue 2, Tailwind CSS, docsearch.js, medium-zoom, clipboard and axios. That is the mechanism behind the visual result. Documentation pages are rendered through a Vue layer rather than as server-rendered HTML, search is provided by docsearch.js, and code blocks get copy-to-clipboard behaviour from the clipboard package. None of this is unusual for a Laravel package of its generation, but it does mean the docs site carries a JavaScript bundle and a build toolchain rather than being plain static HTML.

One consequence worth stating plainly: the package.json declares private: true and lists laravel-mix ^2.0, cross-env ^5.1 and webpack-dev-server ^3.7.2. Those are old pins. If you intend to fork LaRecipe and rebuild its assets yourself, expect to spend time on the front-end toolchain before you touch a single documentation file. If you only consume the package through Composer, the published assets are what you get and the build chain is not your problem.

Installing LaRecipe and publishing your first page

The README gives a two-step install. The first command pulls the package from Packagist under its vendor name, binarytorch/larecipe.

composer require binarytorch/larecipe

The second command runs the package's own Artisan installer, which is what copies the stubs and publishable assets into your application.

php artisan larecipe:install

After those two commands, the README says to visit your app domain with the /docs endpoint. There is no separate server to start and no build step for the documentation content itself; the route is registered by the package. If you see a 404 at /docs, the installer did not complete, or your application is caching its route table.

The README does not spell out where the Markdown files live or what front matter they accept, and it does not document rollback. For those details it defers to the full documentation at larecipe.saleem.dev. That is a real gap in the repository README: the install is two lines, but the day-to-day authoring conventions are documented elsewhere, so treat the linked site as part of the setup, not optional reading.

If you need the extra presentation packages, the README names them individually: binarytorch/larecipe-dark-theme, binarytorch/larecipe-rtl, binarytorch/larecipe-feedback and binarytorch/larecipe-swagger. Each is a separate Composer package, so each is a separate line in composer.json and a separate thing to keep current.

Where LaRecipe is the wrong choice

The strongest limitation is structural rather than technical. LaRecipe only makes sense inside a Laravel application. If your documentation needs to be served when the application is down, or from a CDN edge with no PHP runtime, this package cannot do that. A static generator produces files you can host anywhere; LaRecipe produces a route inside your app.

The second limitation is the front-end stack. The rendered documentation depends on Vue 2 and a Laravel Mix build. Vue 2 reached the end of its support window, and the pinned Mix and webpack-dev-server versions in package.json are from the same era. That does not stop the package from working, but it does mean the docs front end is not on a modern toolchain, and any security review of your dependency tree will flag it.

The third limitation is scope. LaRecipe renders Markdown you write. It is not an API reference generator that inspects your controllers and produces endpoint documentation. The README lists a separate Swagger package as an official add-on, which implies the core does not cover that ground. If your goal is auto-generated reference docs from annotations, you are looking at the wrong layer.

Finally, consider maintenance. The repository is not archived, and the last push was on 2026-09-02. The release history shows v2.9.1 on 2026-06-04, v2.9.0 on 2026-04-03, and v2.8.1 on 2025-07-14. The cadence is irregular rather than steady, and the gap between v2.8.1 and v2.9.0 is roughly nine months. Plan for a package that moves in bursts.

LaRecipe compared with a static documentation generator

The obvious alternative is a static site generator such as VitePress, Docusaurus or MkDocs. The difference is where the documentation lives and what serves it. A static generator produces HTML, CSS and JavaScript files that you deploy to any host. LaRecipe produces a route inside a running Laravel application, with the Markdown files living in that repository.

That changes three things in practice. Deployment: a static site can be published independently of your application release, while LaRecipe docs ship whenever you deploy the app. Access control: docs inside a Laravel app can use the framework's middleware and authentication, which is useful for internal or customer-specific documentation, while a static site needs a proxy or a private host to achieve the same. Toolchain: a static generator brings its own Node-based build, whereas LaRecipe brings a PHP package plus a Vue 2 front end.

There is also the question of where writers work. With a static generator, documentation can be its own repository with its own review process. With LaRecipe, documentation changes go through the application's pull requests. For a small Laravel team that is a simplification. For a team where technical writers are not PHP developers, it is friction.

A second alternative is a hosted documentation platform. Those remove hosting and search concerns entirely, at the cost of moving your content into someone else's system. LaRecipe keeps the Markdown in your repository, which is the property most teams adopting it actually care about.

Licence, upgrades and what a version bump costs

LaRecipe is MIT licensed, and the README points to the LICENSE file in the repository for the full text. MIT is permissive: you can use the package in commercial and closed-source applications, modify it, and redistribute it, provided the copyright notice and permission notice are preserved. This is a general description of the licence, not legal advice, and the LICENSE file in the repository is the authoritative text.

The practical upgrade cost is not the licence, it is the dependency surface. Installing LaRecipe adds binarytorch/larecipe to composer.json, and each optional add-on adds another Composer package. On the front-end side, the package's own build chain is pinned to Laravel Mix 2, webpack-dev-server 3 and Vue 2, though those are development dependencies of the package itself and are not installed into your application unless you fork and rebuild.

Upgrading across minor versions is the thing to watch. The jump from v2.8.1 to v2.9.0 spanned roughly nine months and landed as a minor release, so the changelog in CHANGELOG.md is the place to look before bumping. Because the package publishes assets into your application through php artisan larecipe:install, a version bump can mean re-publishing files, and any local edits to published assets will conflict. Keep published assets out of your own source control, or track them deliberately, before you upgrade.

Editorial conclusion

Adopt LaRecipe if your product already ships as a Laravel app and you want documentation to live in the same repository and deploy pipeline as the code, served from the /docs route the package registers. Do not adopt it if your docs need to stand alone from a Laravel runtime, or if you expect the package to generate reference documentation from source. Before committing, run composer require binarytorch/larecipe and php artisan larecipe:install in a branch and confirm that /docs resolves on your Laravel version, then check the repository history for how recently the package has been touched.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. saleem-hadad/larecipe on GitHub