An alternative approach to drivers

[ozanhazer]

Laravel valet handles all requests through server.php which detects the framework or software project is written, and picks the relevant driver which is responsible of defining the front-controller and the static files. This is a clever approach which enables us to implement any logic programmatically.

However there are some downsides for this approach:

1. nginx configuration for some projects can be complicated due to the needs of the project. The developer will have to write a custom driver in this case to mimic the same logic in php. Nginx configs per project can be updated by directly editing files under ~/.config/valet/Nginx/ but they are reset from time to time I don't know exactly why.

2. Since nginx points to server.php for all requests, it can get in the way when debugging especially if the project already has some issues with the xdebug setup. To pinpoint xdebug problems I usually do "break at first line in PHP scripts" but it stops at the first line of server.php instead of project's front-end controller etc.

3. Sometimes things go wrong with valet configuration and "Valet - Not Found" page is displayed and "Valet" is mentioned in the title only. Also same 404 page is displayed if the problem is caused by nginx or drivers which makes it harder to understand the exact cause of the problem. It got me a lot of times, I know times that I spent hours thinking that the problem is caused by the project itself...

...and maybe some other problems that I cannot remember right now. Usually upgrading php or valet or other packages etc breaks things and I have to start over and dive into valet files again and again which is annoying.

---

So I believe this problem could be solved by removing drivers and server.php, and using nginx configurations instead.

• The framework could be detected while linking the project and relevant nginx configuration could be loaded for that specific project. (nginx config stubs instead of drivers)
• The user can change the nginx stub with a command like valet framework wordpress or valet framework magento etc. (Copy the relevant nginx config stub and restart nginx, simple as that)
• Nginx doesn't complain when wildcards are used for include directives, so adding a include <project_dir>/.nginx*.conf would provide all the flexibility programmer needs. All he/she has to do is add .nginx.conf under project root and add it to global gitignore...
• Instead of custom drivers valet link --with-nginx-config=myconfig.conf would be more than enough for any type of edge cases...

Only complication I could think of is maintaining these three nginx configurations: valet.conf, secure.valet.conf and proxy.valet.conf for each framework but it could be solved by using includes again I think...

I see a lot of open issues regarding custom nginx config needs too, is there any specific reason I am missing for using a server.php?

[ozanhazer]

BTW 15 of the 47 open issues are related to this:

Add location rewrite nginx #982
502 Bad Gateway - nginx/1.19.1 #970
Consider making it easier for users to modify their Nginx config #969
Preventing missing assets from reaching PHP #953
Allow for custom Site Stubs #940
Valet using wrong driver for laravel application #937
should there be a larger fastcgi buffer size in the default nginx config to avoid 502 errors #934
Bedrock driver does not allow pretty permalink rewrites under /wp/ directory #927
Add Drupal 8.7 JSON:API support #771
Trailing slashes in valet #696
Laravel Valet Driver for Prestashop #614
Magento2 Driver with pub as Doc root #592
Bedrock Valet Driver - Non framework PHP files result in framework 404 #539
Slim Framework Driver #522
Drupal multisite subpaths #306

[g3n1us]

If I can add my un-requested opinion. The purpose of using the server.php file along with Drivers is to maintain configuration with PHP, with familiar conventions to Laravel. If you relied on Nginx configuration directly, it would sort of negate the reason for using Valet in the first place, you could just maintain your own Nginx setup on your machine.

Valet follows the coding conventions of Laravel, which makes it a familiar tool for the community.

Also, the vast majority of the example open issues mentioned above are for either very obscure frameworks or for use cases that are ingrained to the use case itself (Drupal multisite...).

I move to close this issue.

[ozanhazer]

From my point of view delegating the webserver configuration to php is not really helping the developer. It's cool, yeah, but it's making things complicated and thus has some drawbacks as I mentioned in the issue description.

Valet supports maybe 99% of use cases with the built-in drivers perfectly and the developer wouldn't even need to write a custom driver at all. So you're right about that issues, they are obscure or some edge cases but that's when you really need to write a driver... And for those cases the nginx solution exists as the developer is already using on their production server.
All they would have to do is to copy the nginx config and make some minor adjustments if needed.

I have a lot of legacy projects to maintain and I have 30+ sites served with valet at the moment. Only 16 of them are laravel projects. I am using valet since the very first day and I don't know how many years has passed but I needed to use a custom driver only once... On the other hand the issues with xdebug or unclear nginx errors happened to me countless times...

And I would have to disagree with "you could just maintain your own Nginx setup on your machine" approach. Valet is not about nginx only, it's a complete development environment setup with a lot of nice features. Maintaining nginx is easy, it's the other features that are not...