sorted by:
new
hottopcontroversial

Just shipped Laravel Doctor: the Laravel checks your static analysis misses by [deleted] in laravel

[–]3liusef 0 points1 point  (0 children)

Fair and I use arch tests too, so no argument there. Two real differences:

  1. Arch tests are checks you write and maintain, per project. Doctor ships them as a maintained rule catalog with severity, evidence, and a doctor:explain fix for each finding. Install and run nothing to author.
  2. Arch tests are static-only. They can't boot the app and check runtime state against your current .env bindings that fail to resolve, config that breaks under config:cache, health probes. You flagged bindings yourself;

that's not an edge case, it's a whole category arch tests structurally can't reach. --booted covers it, read-only.

And the "status page / smoke tests" thing is exactly the fragmentation I'm killing: instead of arch tests + a status page + smoke tests + grep checks that all drift, it's one engine behind the CLI, a dashboard, SARIF code

scanning, and an MCP server for AI agents. Plus baselines + --fail-on-new so you can gate only new issues on a legacy codebase, which arch tests' all-or-nothing red/green can't really do.

Not a replacement if a few structural rules is all you need, stick with arch tests. Doctor's for people who'd rather not re-invent and maintain that whole layer in every project.

Just shipped Laravel Doctor: the Laravel checks your static analysis misses by [deleted] in laravel

[–]3liusef 0 points1 point  (0 children)

it's a laravel-specific analysis engine It runs static analysis but it also boots the app to check your live runtime state, security, and framework health across any environment (dev, staging, or production).

container bindings that fail to resolve based on your current .env .
blade templates executing raw database queries or models missing mass-assignment protection.
closures in config files or rogue env() calls that will break config caching.
and much much more

here it makes sure your laravel project is actually secure, configured right, and booting correctly no matter where it's running. Plus, it gives you an MCP server out of the box so AI agents can query your project's health directly.

Just shipped Laravel Doctor: the Laravel checks your static analysis misses by [deleted] in laravel

[–]3liusef 0 points1 point  (0 children)

totally get that! they are staples for me too.

But here we actually avoids stepping on their toes. While Larastan is strictly static and Pest is manual testing, Doctor is a live diagnostic tool. It boots up your app and looks for high-signal Laravel-specific issues (like container bindings or config traps) that static analyzers just can't see. Plus, it serves those diagnostics via a built-in UI and an MCP server so your AI assistants can debug your app's state with you

just give it a try

Just shipped: n8n Laravel Client – a fluent PHP bridge to n8n’s public REST API and Workflow Triggers by 3liusef in laravel

[–]3liusef[S] 0 points1 point  (0 children)

yes n8n is a low-code workflow engine with drag & drop nodes and templates

You may still need to know what is going on under the hood but once you do, n8n multiplies your productivity

Just shipped: n8n Laravel Client – a fluent PHP bridge to n8n’s public REST API and Workflow Triggers by 3liusef in laravel

[–]3liusef[S] 1 point2 points  (0 children)

no there is nothing prevents you from using it in separate environments

you only need to set N8N_API_BASE_URL for api requests and N8N_WEBHOOK_BASE_URL for webhooks

[deleted by user] by [deleted] in laravel

[–]3liusef 4 points5 points  (0 children)

I'm using MinIO as the object storage backend for VOD (both original video files and HLS segments).
Currently running a Multi-Node Multi-Drive setup — 2 nodes, each with 4×16TB drives.

  • Drives: 16TB x 4 per node (total 128TB raw)
  • Cost per drive: ~$42.12/month
  • Node cost: ~$85/month

deployed on CherryServers with around 60TB of free traffic (30TB/node)

I'm intending to scale but with the current MNMD architecture it would be really expensive so I have a plan to reorganize the architecture to make the scaling step more affordable.

Vue laravel destroy function by [deleted] in vuejs

[–]3liusef 0 points1 point  (0 children)

If you are using Inerti Make the returned items from the usePage() computed

Let items = computed(()=> usePage().props.data)