That's for 4.4 I believe, and we should display nice runtime deprecation notices also.
In 5.0, I'd keep the commands as hidden aliases to display a friendly notice too, in FWB this time.

If we go that way, we should maybe add a special case in flex to ease installing the binary?
That would also need a recipe update, see
https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.2/post-install.txt

See symfony/flex#491

I think it is bad idea.
I dont need any soft other than php on my dev environment. Otherwise I'll just install nginx/apache/etc.

Status: Needs review

@zorn-v The deprecation message mention that you can use the Symfony local web server. But you can use whatever you want indeed. I like the removal of web server bundle as the PHP built-in web server lacks too many needed features (concurrency, TLS support, HTTP/2, ...).

Thank you @Simperfit.

I would not deprecates server:log. The one in symfony is much more powerful (filtering for instance) and does not work like symfony binary works. Instead of parsing logs, it listen on a port, and is able to differentiate client (color prefix). More over the output is more beautiful 😬

There is one fairly important feature that lacks from the Symfony local web server. The ability to specify an IP address of the server. This is mainy useful when you want to bind the server to all network interfaces with 0.0.0.0.

@fabpot

PHP built-in web server lacks too many needed features (concurrency, TLS support, HTTP/2, ...).

Needed very rarely for local development...

Maybe hint in deprecation note like If you want old behavior just run "php -S localhost:8000 -t public" (or maybe php -S localhost:8000 public/index.php) ?

BTW, I found out about "-S" option thanking symfony server start/run command ) just was wondering.

WHY? God why? Who needs tls on local machine? Install nginx ffs, might aswell rename it to symfony global server, because that's what it is, it is system wide binary that I have to install beforehand.

Reasons you might need these features:

• concurrency: as soon as your make AJAX requests or open 2 tabs, to have something similar to the prod (disabling concurrency in the server is a good way to remove all possible race conditions, but will you actually do that in prod ?)
• TLS: as soon as you need to use any modern browser feature that is available only in secure context. And also when you want to use OAuth, as your redirect URL must also be HTTPS by the spec
• HTTP/2: well, if you want to develop using HTTP/2 feature (server push for instance), you'd better be able to test it before reaching the prod.

You can indeed also install nginx locally (and then configure TLS locally if you want that part). That's not forbidden by this PR. This PR is about deprecating WebServerBundle, which is a wrapper around php -S and so suffers from all its limitations.

@lyrixx

There is one fairly important feature that lacks from the Symfony local web server. The ability to specify an IP address of the server. This is mainy useful when you want to bind the server to all network interfaces with 0.0.0.0.

Indeed, I am using a docker-compose network of services (containers) with
command: ["php", "bin/console", "server:run", "0.0.0.0:8000"]
and it won't be possible anymore in Symfony 5.0 🙁

https://github.com/symfony/cli/issues/107 was closed as

This is not supported as of now but we save the idea and will think about it for a future version.

https://github.com/symfony/cli/issues/128 is still open (no answer from team yet)

(and https://github.com/symfony/cli/issues/183 is kinda related too)

Use command: ["php", "-S", "0.0.0.0:8000", "-t", "public", "public/index.php"]
But it is very bad for production. Only one request can handle in one time.

PS. server:run runs php -S by the way.

@zorn-v Thanks, I tested that already, but that is not strictly equivalent (the WebServerBundle adds more options and a custom router.php file)

Edit: Of course not for production, only for development on local machine

https://github.com/symfony/symfony/blob/v4.4.2/src/Symfony/Bundle/WebServerBundle/Resources/router.php

Nothing special

PS. app_dev in comments... from older symfony

The actual reason to clutter developers' logs with this deprecation warning is to push them to use the closed-source "alternative" (https://github.com/symfony/cli/issues/37)

WebServerBundle is by no way deprecated technically. Economically maybe?
There has been no visible debate/ticket/announcement about why this would happen.

Nothing stops anyone from producing closed-source by-products or sell commercial services.
But a too aggressive promotion of a closed-source solution can only harm the overall software ecosystem.

Taking advantage of a large user-base trusting this software (and its open-source quality) to push a closed-source tool as the only development alternative is a really bad move I suggest you reconsider (the fact that this, mostly confidential, PR is already the 4th most down-voted one should be hint... until comments get closed here too)

As one of the thousands of developers who won't install an opaque binary for their development, I strongly hope that maintenance PR for the webserver-bundle will not be discarded.

• The first step would be to create a dedicated repository (like for other bundles)
• Revert this very PR that attempt to drop a working solution for no technical reason.
• Push a 5.x tag

By chance this deprecation does not affect production servers. But from now on... who knows what could come next?

NB: Just found https://www.reddit.com/r/PHP/comments/foqs7x/symfony_docs_make_it_look_like_you_have_to_use/ :

It at least feels like they artificially broke compatibility, by not bumping it to version 5.0, to promote the closed source binary.

This answer in the reddit thread you linked perfectly explains the rationale and the alternative that is in your hands. Now locking since shaming won't help anything nor anyone.