Login

u/3liusef

r/PHP r/ERPNext_Solution r/laravel
I built an open-source Laravel client for ERPNext and Frappe
▲ 22 r/ERPNext_Solution+1 crossposts

I built an open-source Laravel client for ERPNext and Frappe

I've released kayedspace/laravel-erpnext, an MIT-licensed package for connecting Laravel applications to ERPNext and Frappe.

The main design decision was to treat DocTypes as generic resources. You can work with a standard or custom DocType by name without creating a PHP class, mapping, or registration first:

use Kayedspace\Erpnext\Facades\Erpnext;

$overdue = Erpnext::doctype('Sales Invoice')->query()
    ->where('status', 'Overdue')
    ->fields(['name', 'customer', 'outstanding_amount'])
    ->orderBy('creation', 'asc')
    ->limit(200)
    ->get();

The package also includes:

  • Token, Basic, Bearer, and cached Session authentication.
  • Frappe-aware filters and full-result pagination with each(), chunk(), and lazy().
  • Create, read, update, delete, and whitelisted document method calls.
  • Private-by-default file uploads, attachments, image optimization, and authenticated downloads.
  • Multi-tenant connection resolution and focused retries for rate limits or unavailable sites.
  • Optional typed wrappers for eight common DocTypes, including invoice and payment submission lifecycles.

I tried to keep the generic API as the normal path and make typed documents optional. ERPNext still decides required fields, permissions, custom fields, and which document methods are available.

Installation is:

composer require kayedspace/laravel-erpnext

Source: https://github.com/kayedspace/laravel-erpnext

Documentation: https://laravel-erpnext.kayed.dev

I would especially value feedback from people maintaining real Laravel-to-ERPNext integrations. Which part usually causes the most trouble in your projects: authentication, DocType queries, document lifecycles, files, or keeping local and ERPNext records synchronized?

u/3liusef — 6 days ago
▲ 0 r/PHP+1 crossposts

Just shipped Laravel Doctor: the Laravel checks your static analysis misses

I've been chipping away at this for months, and I'm genuinely proud to finally put it out there: Laravel Doctor.

Here's the itch it scratches.
Every Laravel team I've worked on has an unwritten checklist living in the head of whoever's been there longest.

  • An env() call sitting outside a config file, quietly breaking the moment you run config:cache.
  • A raw request string passed straight into a shell command.
  • A route that shipped to production with no auth middleware.
  • APP_DEBUG=true waiting to leak stack traces on your live site.
  • A Model::all() inside a Blade loop, turning one page load into a thousand queries.
  • Mass assignment wide open — no $fillable, no $guarded.
  • dd(), dump(), or ray() left behind in committed code.
  • A migration with no down() method, so nothing rolls back cleanly.
  • Queued jobs dispatched with no failure handling or retry limit.
  • A where() built from raw user input instead of bindings.
  • Storage or cache writes assuming local while prod runs s3 or redis.
  • Secrets hardcoded in config instead of pulled from the environment.

PHPStan and Larastan are great, but they don't really know Laravel. they'll tell you a type is wrong, not that you just broke config:cache

So I built a tool that does know. It all starts from one command

php artisan doctor:scan

It runs Laravel-aware rules against your project and reports each finding with the file, the evidence, and remediation for it.

The part I'm proudest of: one engine, many surfaces. The exact scan you run in your terminal is the same

scan behind the dashboard, the HTTP API, a SARIF export for GitHub code scanning, and an MCP server your AI assistant can call. No shelling out, no drift between "what CI checks" and "what I check locally."

What makes it actually usable day to day:

  • Git-aware scans : --changed, --staged, --base=main. Scan only what your PR touches instead of drowning in the legacy codebase.
  • Baselines : got 400 existing findings? Snapshot them and only fail CI on new ones. Adopt it without a cleanup sprint first.
  • Rule packs : start with just --pack=security if that's all you can stomach.
  • Machine output : JSON and SARIF, straight into CI and GitHub's code scanning tab.
  • MCP tools : I use it with an AI coding agent to review my own changed files before I even open a PR. Read-only, so the agent can look but not touch.

Static rules never boot your app. Runtime checks are opt-in and stay read-only. It rejects path traversal and redacts secret-looking values before serializing reports — I really didn't want a diagnostics tool to become the thing that leaks your .env.

Works on Laravel 11, 12, and 13, PHP 8.2+

composer require kayedspace/laravel-doctor

php artisan doctor:scan

Repo: https://github.com/kayedspace/laravel-doctor

Docs: https://laravel-doctor.kayed.dev

This is just the first release and I'm actively building the rule catalog out. If there's a Laravel footgun that's bitten you that a tool could have caught, drop it below

that's literally my backlog. And if you try it, tell me where it's noisy or wrong. I'd love the feedback.

github.com
u/3liusef — 1 month ago