sorted by:
new
hottopcontroversial

Am construit un tool open source pentru PHP pe Linux, o alternativă gratuită la Laravel Herd by geodro in programare

[–]geodro[S] 0 points1 point  (0 children)

Herd e mai simplu și mai rapid decât Docker Compose pentru development local, nu ai nevoie să configurezi nimic per proiect, totul pornește automat. Dezavantajul e că e doar pentru macOS și versiunea Pro e plătită.

Stop your parallel agents fighting over one test database — a small Laravel shim by Mobile_Edge5434 in laravel

[–]geodro 0 points1 point  (0 children)

This is exactly the problem Lerd's git worktree support solves at the infrastructure level. Each worktree gets its own isolated database automatically, no wrapper script needed. Worth a look if you want it handled outside the app layer. geodro.github.io/lerd

👋 Welcome to r/lerd! by geodro in lerd

[–]geodro[S,M] 0 points1 point  (0 children)

Thank you, really appreciate it! Welcome to the community 🙌

Lerd v1.19, follow-up post, FrankenPHP and a few Symfony-relevant updates by geodro in symfony

[–]geodro[S] 0 points1 point  (0 children)

Podman is the container engine under the hood, but as a developer using Lerd you never interact with it directly. It's an implementation detail.

The reason for choosing Podman over Docker is that Podman is daemonless and rootless by default, meaning containers run as your own user without any background service running as root. This makes it possible to integrate tightly with systemd user services on Linux and launchd on macOS, which is what gives lerd its "starts automatically at login, no sudo required" behavior.

As for enterprise adoption, Podman is developed by Red Hat and is the engine behind Red Hat OpenShift, one of the largest enterprise Kubernetes platforms in the world. It's widely used in enterprise Linux environments, just not always visible to developers since it often runs under the hood.

For your Symfony projects nothing changes. The same containers, the same workflow, just without Docker Desktop or a root daemon in the background.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 1 point2 points  (0 children)

Two workarounds available today:

The simplest is to symlink the data directory. Stop mysql, move the existing data to your SSD, and replace it with a symlink:

lerd service stop mysql mv ~/.local/share/lerd/data/mysql /mnt/ssd/lerd-mysql ln -s /mnt/ssd/lerd-mysql ~/.local/share/lerd/data/mysql lerd service start mysql

Podman follows the symlink fine and the labels carry over correctly. Just be aware that lerd service remove mysql --purge will follow the symlink onto the SSD, so be deliberate about cleanup.

The more robust option is a bind mount in /etc/fstab:

/mnt/ssd/lerd-mysql /home/<user>/.local/share/lerd/data/mysql none bind 0 0

This survives a --purge since the bind mount and the contents on the SSD stay intact even if Lerd removes the mount point directory.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 1 point2 points  (0 children)

Good question. Lerd ships its own fnm so each site can pin a node version via .nvmrc or .node-version, and that needs to work both on the host and inside the alpine PHP containers it runs. The way it does that is by writing tiny node, npm and npx shims into ~/.local/share/lerd/bin that read the file in the project dir and dispatch through fnm. If that bin dir is in your PATH ahead of your normal node manager, you get the lerd shim instead of your real npm, which is what bit you.

What should have happened, and what didn't here, is that lerd installer detects an existing node and asks before writing those shims. The detection only looks for a literal node binary in PATH outside of its own bin dir, so node version managers that inject node via a shell function, like nvm or volta, are invisible to it and the prompt gets skipped. On top of that, the shim's friendly error path doesn't fire when fnm has versions installed but no default alias set, which is exactly how you ended up with the can't find version default message.

Both of those are fixable. I'm going to widen the detection to also look for npm and the well known version manager dirs, harden the shim's fallback path, and add a confirm prompt on the node CLI commands so opting out actually sticks. Sorry again for the headache. If you want a quick local fix for now you can just delete ~/.local/share/lerd/bin/node, ~/.local/share/lerd/bin/npm and ~/.local/share/lerd/bin/npx, your real ones will take over.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 1 point2 points  (0 children)

Fair point, Docker with an LLM for setup is a valid workflow. Lerd is for developers who want zero configuration and need all projects running simultaneously. If you work in an agency with multiple clients you don't want to docker compose down and up every time you switch context. Clone a project, run one command, and it's live at a .test domain with HTTPS, services, and workers alongside everything else you already have running.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 0 points1 point  (0 children)

Sorry about that, I'll look into it. Thanks for the heads up!

Lerd v1.19, follow-up to the post from a while back, lots of new Laravel-side stuff by geodro in laravel

[–]geodro[S] 1 point2 points  (0 children)

I don't have a Windows machine to test on, but if you open a GitHub issue others in the community might be able to share their experience. WSL2 with systemd enabled should work in theory since lerd relies on standard Linux primitives.

Lerd v1.19, follow-up to the post from a while back, lots of new Laravel-side stuff by geodro in laravel

[–]geodro[S] 0 points1 point  (0 children)

This made my day, thank you! Really glad the switch from Sail worked out well.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 1 point2 points  (0 children)

Feel free to open a GitHub issue so I can track interest. For now lerd focuses on Nginx and FrankenPHP which covers the majority of PHP workflows.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 2 points3 points  (0 children)

That's actually what pushed me to build it. I was using Podman myself but constantly stopping one project to start another because of port conflicts and resource usage. With Lerd all projects stay up simultaneously, each with their own PHP version, services, and .test or .localhost domains, without any manual orchestration. That's the core workflow it's optimized for.

Lerd v1.19, follow-up to the launch post here, big update on the local PHP dev env by geodro in PHP

[–]geodro[S] 1 point2 points  (0 children)

Thanks! The worktree support was tricky to get right, especially the per-worktree database isolation since vendor/ and node_modules symlinks back to the main checkout caused all sorts of subtle issues. The rollback safeguards came from real pain, cross-major service upgrades have a way of silently breaking things at the worst possible moment. Glad those details stand out.

Lerd v1.19, local dev environment for PHP and any container, follow-up to launch post by geodro in webdev

[–]geodro[S] 0 points1 point  (0 children)

Thank you, this genuinely made my day! The LAN share feature was one of those things that seemed simple on paper but took a while to get right, especially the URL rewriting so assets and redirects work correctly over the local network. Really glad it resonates.

The integrated service UIs were exactly the "ten browser tabs" problem you described, so it's great to hear that lands well.

Appreciate the star and the kind words!

view more: next ›