- How do I install guanguans/laravel-dump-sql in a Laravel app?
- Run composer require --dev guanguans/laravel-dump-sql and let Laravel's package auto-discovery register the service provider. There is no config file to publish, no migration to run, and no credentials to supply. Verify the install with a one-line smoke test in tinker against a known query, such as User::limit(1)->dumpSql(). Because it is a leaf dev dependency, it does not need to appear in your production build.
- Which Laravel and PHP versions does laravel-dump-sql support?
- The package declares its PHP and Laravel constraints in composer.json, so check those against your application's versions before installing. The last tagged release was 2024-03-14, so newer Laravel major versions may be declared but are not necessarily exercised in CI. The macros rely on relatively stable builder methods like toSql() and getBindings(), but macro registration on builder classes is sensitive to Laravel major-version refactors, so run a quick smoke test after every framework upgrade.
- How do I use dumpSql() and ddSql() to see the full SQL query?
- Chain the macro directly onto a query instead of calling toSql(): User::where('active', true)->dumpSql() prints the complete statement with bindings substituted for the question marks. ddSql() does the same and then dies, so it is a natural replacement for the usual toSql() plus hand-substitution workflow. Both macros are registered on the query builder, so they work anywhere a builder instance is available, including inside Eloquent scopes and relationships.
- Does it work on the query builder as well as Eloquent models?
- Yes. The macros are registered on the underlying builder classes, so DB::table('users')->where('id', 1)->dumpSql() works exactly like the Eloquent equivalent. That also means it applies to relationship queries, subquery closures, and any code path that returns a builder instance. Interpolation quality depends on the bindings involved, not on whether the query started from Eloquent or the plain query builder.
- Can I log the interpolated SQL instead of dumping it to the screen?
- The package ships helpers for logging queries in addition to the dumpSql() and ddSql() macros, which is useful for CI jobs and requests where terminal output is not visible. Logging carries the same data-exposure caveats as dumping, so treat log files and CI artifacts as a place where bound values, including emails and tokens, may now appear. If you need masking, wrap the call in your own helper that redacts sensitive bindings before writing.
- Is laravel-dump-sql safe to use in production?
- It should be installed with require-dev and excluded from your production --no-dev build, since it is a debugging convenience and nothing in your application depends on it. The bigger risk is data handling: inlining bindings means real secrets, emails, and PII land in terminal scrollback, log files, or CI artifacts, and the package has no built-in redaction hook. Adopt an explicit rule of never running it against production data, or skip the dependency entirely.
- Does it correctly handle whereIn arrays, subqueries, and raw expressions?
- Treat the output as indicative rather than executable. Interpolation is essentially string surgery with heuristic quoting for strings, dates, booleans, null, and binary values, and the classic failure points are large whereIn arrays, deeply nested subqueries, having clauses, unions, and raw expressions. The result can look plausible while being wrong or unrunnable, so never paste generated SQL into a production console. Confirm anything important against an actual query log or database client.
- How does laravel-dump-sql compare to Laravel's native toRawSql()?
- Recent Laravel 10.x and 11.x releases added toRawSql() on the query builder, which returns the statement with bindings inlined and removes much of this package's original reason to exist. The package still adds the convenience of dumpSql() and ddSql() as one-call macros plus query logging helpers. If you are on a modern Laravel version, standardize on toRawSql() or Telescope first and only reach for this package if the macro ergonomics genuinely help your team.
- Is laravel-dump-sql still maintained and can I fork it if it is abandoned?
- Maintenance signals are weak: roughly 36 stars, a single maintainer, and a last release in March 2024, so the bus factor is effectively one. Nothing else depends on it and removing it changes no application behavior, which keeps the exit cost low. The functionality is only around 100 to 200 lines, so forking and vendoring it internally is a realistic fallback if the maintainer goes dormant or a Laravel upgrade breaks the macros.
- Does it work with multiple database drivers like MySQL and PostgreSQL?
- The package takes no database driver, queue, cache, or event-loop footprint, so it runs anywhere, but the interpolation heuristics may not match every driver's quoting rules. If your application targets more than one engine, for example MySQL and PostgreSQL alongside SQLite in tests, verify the generated SQL against each driver before trusting it. Teams running a single RDBMS get the most value; mixed-engine stacks are where silently wrong output is most likely.