Laravel 5 Heroku Local doesn't work

I've successfully deployed the Laravel application to Heroku.

It works online.

But when I try to run "heroku local" I get:

vendor/bin/heroku-php-apache2: No such file or directory

Which makes sense, since looking into "vendor/bin", the only thing listed is:

psysh -> ../psy/psysh/bin/psysh

So, where's my heroku-php-apache or how do I fix this?

回答1:

You should have these lines in your composer.json

"require-dev": {
    "heroku/heroku-buildpack-php": "*"
 }

be sure to run composer update after you add them.

回答2:

After extensive research, trial and error and talking to the Heroku Support team, I found out that, although Slow Loris's answer was a part of the process, the following answer was given to me by Heroku's Support:

To cut a long story short, heroku local is not officially supported for PHP >applications. The reason is that unlike all the other languages we support on the >platform, PHP has no web servers written in userland. Instead, we use PHP-FPM >together with Apache or Nginx, and the boot scripts (vendor/bin/heroku-(php|hhvm)-(apache2|nginx)) dynamically inject the correct configuration for port >binding and the FastCGI comms sockets.

This works with vanilla PHP and Apache builds, provided that:

1) the current user has all the correct permissions (in your case, >/var/log/apache2/ isn't writable); 2) the correct proxy modules are loaded in the main httpd.conf; 3) the main httpd.conf doesn't bind to a port at all, or at least not to one >under 1024 (which are reserved for superusers).

The main config also needs to be handled by each user on their own, because >sometimes, the modules to be loaded are in libexec/, sometimes in >lib/apache2/modules/, and so forth. Just too many variations; otherwise, we could >ship a full Apache config to users and the experience would be much better.

But the problems don't end there. FPM does not work at all on Windows, and on >most Linux systems, httpd is not a command that works; instead, apache2ctl >handles starting and stopping, and thus, running a server in the foreground is >not possible. In the end, there are simply too many possible permutations in >system configs that make it impossible to ensure every user has a great >experience.

It's simply the current reality in PHP land. Ruby, Python, Node, Java all have >web servers that are written in each respective language, and you don't need >external servers. Which also makes it possible to stream file uploads, handle web >socket upgrades, and so forth. Maybe with PHP 7 we'll see something like that >emerge soon (in PHP 5 it's simply not feasible at all, because a fatal error >kills the engine, so your web server would be gone too).