Coder Social home page Coder Social logo

lumen-framework's Introduction

Lumen Framework (Kernel)

Build Status Total Downloads Latest Stable Version License

Note: This repository contains the core code of the Laravel Lumen framework. If you want to build an application using Laravel Lumen, visit the main Lumen repository.

Lumen PHP Framework

Laravel Lumen is a stunningly fast PHP micro-framework for building web applications with expressive, elegant syntax. We believe development must be an enjoyable, creative experience to be truly fulfilling. Lumen attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as routing, database abstraction, queueing, and caching.

Official Documentation

Documentation for the framework can be found on the Lumen website.

Contributing

Thank you for considering contributing to Lumen! The contribution guide can be found in the Laravel documentation.

Security Vulnerabilities

Please review our security policy on how to report security vulnerabilities.

License

Laravel Lumen is open-sourced software licensed under the MIT license.

lumen-framework's People

Contributors

antonkomarev avatar arrilot avatar carusogabriel avatar chimit avatar crynobone avatar driesvints avatar fire015 avatar gmsantos avatar grahamcampbell avatar jaoued avatar jasonlewis avatar jensdenies avatar kieranbrown avatar lidbetter avatar lloricode avatar lukasgeiter avatar lvismer avatar martinparrish avatar martinssipenko avatar molteber avatar nunomaduro avatar owenvoke avatar sahanh avatar scrubmx avatar stevenwadejr avatar taylorotwell avatar themsaid avatar thybag avatar troydavisson avatar zakhenry avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lumen-framework's Issues

How do I handle before router ?

Hello @taylorotwell ,

How do I handle the before router event? like laravel/framework does...

I need before any route check if method is OPTIONS and return new response or inject some CORS headers: Like https://github.com/barryvdh/laravel-cors/blob/master/src/CorsServiceProvider.php#L53

Because without that, I have to dynamic create an route->options do any request, like:

https://gist.github.com/vluzrmos/1238a0c81bfd90853f58

Also, I tried to do that on middlewares, but doens't works too.

public function handle($request, Closure $next)
   if($request->isMethod('OPTIONS')){
       return new Response('OK', 200, $headers); //the cors headers
   }

  return $next($request);
} 

Thanks!

artisan up & down

@taylorotwell would you consider bringing "back" to lumen the php artisan up and php artisan down command?

Don't know if I'm alone but I'm missing it.
What is the reason you omitted it?

:-)

URLs with trailing slashed not recognized as in Laravel 5

When writing in routes.php in Lumen 5.0.8:

$app->get('welcome', function() { return 'Hello'; });

It responds to http://mysite.dev/welcome but with a trailing slash http://mysite.dev/welcome/, the site throws a 404. Unlike Laravel 5, where both URLs are recognised as the same.

One example problem is that I use the class LengthAwarePaginator with the method nextPageUrl() which generates an URL with a trailing slash.

What is the long term support for Lumen?

I'm building out microservices using Laravel right now. I'd like to use Lumen because I don't need views. Should I switch over to Lumen?

Is there a swift way to go from lumen to laravel and vice versa? Assuming I don't views, and what not.

How can I specify branch 5.0 in composer?

I want to install the latest version of 5.0 branch, but composer always pull the releases. How can I tell it to ignore the releases tags?

I already searched in other places for the solution, cannot find anything helpful.

Default PHP function parameters break routes

Hi,

There seems to be an issue with having default values for methods in a controller.

public function get_orders(Request $request, $id){} // This works fine
public function get_orders(Request $request, $id = "test") {} // This does not

The parameter $id will always be set as its default value inside the function.

Example Route:

$app->get('/orders/{id}', "App\Http\API\Orders\Orders@get_orders");

Example Controller:

class Orders extends CoreApi {

    public function get_orders(Request $request, $id = "test"){
    ...
    }
}

Example URL:

www.myapp.com/orders/MY_VALUE

I can see that in Container.php on line 524 lumen is calling the function get_orders using call_user_func_array with the following array even though the function only takes two parameters ($request and $id).

Array (
    [0] => Illuminate\Support\Facades\Request Object ( )
    [1]  => test
    [2] => MY_VALUE
) 

It appears that the default values are not being overridden with the actual values and instead are being simply appended to the end of the array.

From what I can gather this bad array is being created in the function getMethodDependencies(). It seems to be merging two separate arrays.

protected function getMethodDependencies($callback, $parameters = [])
    {
        $dependencies = [];

        foreach ($this->getCallReflector($callback)->getParameters() as $key => $parameter)
        {
            $this->addDependencyForCallParameter($parameter, $parameters, $dependencies);
        }

        return array_merge($dependencies, $parameters);
    }

The $dependencies array is all the parameters from the get_orders function signature found by using reflection.
The $parameters array is the values provided by the router which are taken out of the URL.

I can see that before the array merge happens $dependencies has a value of:

array(
    [0] => Illuminate\Support\Facades\Request Object ( )
    [1]  => test
)

and $parameters has a value of:

array(
    [0]  => MY_VALUE
)

From that code I don't see how the parameters provided from the URL could ever overwrite the defaulted $id parameters value?

The array merge just seems to append the real value of id to the end of the array. This means the function which takes two parameters (Request $request, $id = "test") is passed three parameters with the real value not being assigned to any variable in the signature of the method.

I hope this comes across clearly.

Is this an issue with the code or is the router not designed to have functions with defaulted values parameters?

Lumen Config Files

Lumen will use your copy of the configuration file if you copy and paste one of the files into a config directory within your project root.

Doesn't seem to be the case. project/config/app.php exists, but it's not present when doing config() or config('app.key'). Only when I register the configuration file with $app->configure('app'); does it successfully load.

Weird thing is, database.php does seem to load.

Utilizing Pipeline Earlier In Lifecycle

I need to get some feedback here on whether the current approach is ideal in terms of when the pipeline is used and whether or not it should be used earlier.

Currently when the application is run it immediately calls the dispatch method, which in turn will check for the existence of a route. Eventually we'll hit the handleFoundRoute method if all went well. Now, here is where we first encounter the pipeline. The request is sent through the pipeline and the global middlewares are applied. Then we hit the handleArrayBasedFoundRoute method and the pipeline is used once again for the route middlewares.

Now, I'm thinking your reasoning here was to avoid piping through the middlewares too early. Not sure how much of a performance increase you'd get by doing this. I haven't tested. But, would it not make more sense to pipe the request through first, then dispatch it. Seems like things are happening backwards here...

My thoughts are this would clean it up a bit. Currently the prepareResponse method seems to be called too many times. It actually looks like it's being called on responses that will already be prepared.

If you're curious I'll gladly do a few tests and what not to see how much of a performance hit it takes by piping first.

(Note: The reason for this issue is mainly because this is one of the bigger difference between the routing setups of L5 and Lumen. I've found that L5 pipes first, meaning I can capture the request before the dispatcher even gets to it. Lumen... The route must exist before the middlewares are even looked at.)

[Bug] Request parameters lost when unit testing

@taylorotwell

Laravel\Lumen\Testing\ApplicationTrait doesn't seem to be working as expected\intended. In summary:

  • Hitting routes via browser/curl works as expected, with request parameters being present.
  • Hitting routes via unit testing methods does not work as expected, with request parameters being empty.

It seems I'm not alone with this:

Code:

routes.php:

$app->get('/', ['as' => 'getIndex', function() use ($app)
{
    $request = $app->make(\Illuminate\Http\Request::class);

    dd($request->all());
}]);

FooTest.php

public function test_foo_bar()
{
    $response = $this->call('GET', '/', ['foo' => 'bar']);
}

Package publishing

Is there any plan to implement vendor publishing in Lumen? I seem to be successful in porting a few Laravel packages over to Lumen fairly easily, however the manual movement of migration and config files is fairly awkward to say the least :-)

[BUG] Lumen Unit Test - Strange Behaviors

Here my TestCase class:

<?php

use Illuminate\Support\Facades\Artisan;
use App\Models\User;

class TestCase extends Laravel\Lumen\Testing\TestCase {

    /**
     * Creates the application.
     *
     * @return \Laravel\Lumen\Application
     */
    public function createApplication()
    {
        return require __DIR__.'/../bootstrap/app.php';
    }

    public function setUp()
    {
        parent::setUp();
        $this->refreshApplication();
        Artisan::call('migrate');
    }

    public function tearDown()
    {
        Artisan::call('migrate:reset');
    }

}

And here my test scenario:

<?php

use App\Models\User;
use App\Models\Observers\User as UserObserver;

class UsersControllerTest extends TestCase {

    public function testRegisterSuccess()
    {
        $params = [
            'email' => '[email protected]',
            'password' => 'testing',
            'password_confirmation' => 'testing'
        ];

        $response = $this->call('POST', '/api/v1/users/register', $params);
        $json = json_decode($response->getContent()); 

        $this->assertResponseOk();

        /*
         * check and test json response
         */ 
        $this->assertTrue(isset($json->status));    
        $this->assertTrue(isset($json->data));    
        $this->assertEquals('success', $json->status); 
        $this->assertTrue(empty($json->data));

        /*
         * check and test database data
         */
        $user = User::where('email', '[email protected]')->first();
        $this->assertTrue(!empty($user));
        $this->assertTrue(isset($user->email));
        $this->assertEquals('[email protected]', $user->email);        
    }

    public function testRegisterFailedEmailExists()
    {
        $this->generateUser('[email protected]', 'testing');

        $params = [
            'email' => '[email protected]',
            'password' => 'testing',
            'password_confirmation' => 'testing'
        ];

        $response = $this->call('POST', '/api/v1/users/register', $params);
        $this->assertResponseStatus(400);

        $json = json_decode($response->getContent());

        $this->assertTrue(isset($json->status));
        $this->assertEquals('error', $json->status);

        $this->assertTrue(isset($json->message));
        $this->assertEquals('Fail to validate.', $json->message);
    }

    public function testRegisterEmptyParams()
    {
        $response = $this->call('POST', '/api/v1/users/register', []);
        $this->assertResponseStatus(400);

        $json = json_decode($response->getContent());

        $this->assertTrue(isset($json->status));
        $this->assertEquals('error', $json->status);

        $this->assertTrue(isset($json->message));
        $this->assertEquals('Fail to validate.', $json->message);
    }

    private function generateUser($email, $password)
    {
        User::observe(new UserObserver);
        $user = new User;
        $user->register($email, $password);
    }
}

When i run for each test like :

./vendor/bin/phpunit --filter testRegisterEmptyParams

It works fine, here my screenshot :
lumen_test_empty_params

but, when i run all tests :
lumen_all_tests

What happened here?

withFacades() should accepts a parameter indicating the fascades that should not be loaded

I was incorporating Lumen to a legacy PHP application today and encountered some problems with re-declaring classes.

The existing PHP application already have a Cookie and DB class declared which conflicted with Lumen's fascades.

It would be useful if the $app->withFascade() function accept a parameter indicating only the fascades to be loaded or maybe the fascades not to load/

Something like:

Application->withFacades($without)

$app->withFacades([
    'DB',
    'Cookie'
]);

I can do a PR if this enhancement is wanted.

Nesting route groups doesn't work

My routes.php looks like this:

// API v1
$app->group(['prefix' => 'v1'], function($app) {
    $app->get('/', function() {
        return 'root';
    });

    // Users
    $app->group(['prefix' => 'users'], function($app) {
        $app->get('/', function() {
            return 'users';
        });
    });
});

When calling /v1 it returns root, but when calling /v1/users a NotFoundHttpException is thrown. This works in Laravel as far as I know. Is this intentionally not working in Lumen? FastRoute doesn't provide the route grouping itself, that's why I thought it may be a bug in Lumen.

Basepath is set to public directory

Since support for built-in PHP server has been added, my basepath is set to public/.

This triggers the following error on every pageload since Monolog is looking for the log file in the wrong directory.

[Thu Apr 30 20:31:00 2015] PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'The stream or file "/var/www/project/public/storage/logs/lumen.log" could not be opened: failed to open stream: No such file or directory' in /var/www/project/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php:84

When removing the added || php_sapi_name() === 'cli-server' from the above linked commit, everything works as expected. The basepath is now set to /var/www/project/.

I am running my app on Ubuntu 15.04 via php artisan serve. php_sapi_name() returns cli-server.

PHP 5.6.7-1+deb.sury.org~vivid+1 (cli) (built: Mar 24 2015 11:23:09)

ValidatesWhenResolved not working.

If request implements ValidatesWhenResolved (i.e. via ValidatesWhenResolvedTrait), it is not validated automatically.

I have following request class (in short)

class FormRequest extends Request implements ValidatesWhenResolved {

    use ValidatesWhenResolvedTrait;

}

ValidationServiceProvider::registerValidationResolverHook is executed as expected, but (looks like) after Request is resolved, thus afterResolving is not executed.
This portion of code is never executed

$this->app->afterResolving(function(ValidatesWhenResolved $resolved)
        {
            $resolved->validate();
        });

I registered Illuminate\Validation\ValidationServiceProvider in App\Providers\AppServiceProvider which at least started to call validate method on Request but fails on resolving validator. It interferes with app's https://github.com/laravel/lumen-framework/blob/5.0/src/Application.php#L684 (recursive calls?)

Am I trying to run feature which is not actually supported or is there a bug?

add Queue from controller

I try to add new job into queue from controller:

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
use Illuminate\Queue\Queue;
class SaveController extends Controller
{
public function save(Request $request, Queue $queue)
{
    $q = $queue->pushOn('getSent', new \App\Jobs\SomeJobs('hello'));
    return $q;
}
}

but i catch error:

lumen.ERROR: exception 'Illuminate\Container\BindingResolutionException' with message 'Target [Illuminate\Queue\Queue] is not instantiable.' in /var/www/lumenlocal/lumen/vendor/illuminate/container/Container.php:785

What's wrong?

Packages don't work!

I know Lumen is not trying to be Laravel but there are several packages out there that could've been used with Lumen, but due to some helper functions, it doesn't work with Lumen.

For example database_path one of the packages i was trying to use with Lumen throws undefined fatal error, similarly there are few other helper functions that are common with Laravel but due to no support in Lumen, it doesn't work.

Why can't we have these small helpers common in Laravel, So that we can use all those amazing Packages out there with Lumen too?

Currently, I end up manually adding package service providers into my custom service providers but that's really not a good thing TBH.

Issue regarding middleware parameters

In middleware in Laravel 5 you can add middleware specific parameters like this:

// In your routes
Route::group(['middleware' => 'acl', 'role' => 'admin'], function(){});

// In your middleware
$request->route()->getAction()['role'];

In Lumen $request->route()->getAction() doesn't exists.
To replicate the Laravel 5 behaviour, you would to this:

$request->route()[2]['role'];

But you can't add the middleware parameter in a $app->group, like so:

$app->group(['middleware' => 'acl', 'role' => 'admin'], function(){});

Instead you have to add the parameter to your specific route, like this:

// Routes
$app->group(['middleware' => 'acl'], function()
{
    $app->get('roles', ['uses' => 'App\Http\Controllers\RoleController@index', 'role' => 'admin']);
});

// Middleware
$request->route()[2]['role'];

I would like to be able to add the additional middleware parameters in a route group (like in above L5 example), or within a controller like this: $this->middleware('acl', ['role' => 'admin']);

I'm not sure where to look in order to create/correct this behaviour in Lumen, but I would grate full if this could be added.

Thank you for reading this.

Examples of use in Laravel 5:

FilesystemServiceProvider - Allowed memory size exhausted

I'm using Lumen as a gateway for files hosted on DreamObjects. I've created a facade named CloudStorage which accesses the filesystem.cloud singleton defined in Illuminate\Filesystem\FilesystemServiceProvider. This gives me an easy facade to use for working with the default cloud storage filesystem, whilst retaining Storage for any local storage operations.

The facade is in app/Facades/CloudStorage.php and is namespaced properly. It works fine in Laravel 5 but using Lumen throws out an allowed memory size exhausted error from PHP . The full error is:

Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 130968 bytes) in <app_path>/vendor/illuminate/container/Container.php on line 366

$app->withFacades(); is present in bootstrap/app.php, as is a class_alias() call for the facade itself. I've also added $app->register('Illuminate\Filesystem\FilesystemServiceProvider'); to register the service provider. If I comment this line, I get a different error, this time from Lumen: Class filesystem.cloud does not exist.

The second error makes sense as the FilesystemServiceProvider obviously isn't registered. However when it is registered, the allowed memory error appears.

I could work around this by using Storage::disk('dreamobjects_fs') for each DO operation, but I'd rather keep things simple with just a single facade.

Any ideas on this?

Fatal error due to new methods in Illuminate Application interface

Following Pull Request to laravel 5.1 has raised Fatal error on lumen 5.1 laravel/framework#9135

Fatal error: Class Laravel\Lumen\Application contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (Illuminate\Contracts\Foundation\Application::getCachedCompilePath, Illuminate\Contracts\Foundation\Application::getCachedServicesPath)

Setting a custom resource path for the application is not working

I want my templates reside under app/views directory.
Right after creating the application object I set custom resource path but the app still tries to find the views inside resources/views directory.

$app = new Laravel\Lumen\Application;
$app->useResourcePath($app->basePath('app'));

Database refresh doesn't work within Unit testing

Every time we try to reset the database (migrate:refresh and seed) from the testing box (phpunit) we get this exception:

exception 'ReflectionException' with message 'Class config does not exist' in /www/vendor/illuminate/container/Container.php:776

Replication steps:

  1. In your TestCase base class (commonly located in /tests folder) override method setUp and define it like this:
public function setUp()
{
     parent::setUp();
     $this->artisan('migrate:refresh');
     $this->seed();
}
  1. Run tests from the console using phpunit command.

Note: this issue also happens if you try to wrap the test within a database transaction and roll it back at the end of the test:

public function setUp()
{
    parent::setUp();
    DB::beginTransaction();
}

public function tearDown()
{
     DB::rollback();
     parent::tearDown();
}

Custom session driver

Creating custom session driver (memcache http://laravel.io/bin/PXXQz ! NOT memcached)
If i am trying to set session id ($app->session->setId(session_id()) and save it ($app->session->save())
It throws me an error (undefined index _sf2_meta) If i do it before SessionStart middleware it gives out that i dont have session driver set.
So i register provider before this middlewares (my custom session driver middleware) and then it starts session BUT it keeps regenerate session id or something like that. I have set session id length to 40, same as in my php settings i use ("session.name", "laravel_sessions")
as you can see i have implemented memcache driver and it seems correct. I can dump out data in read method (dd($this->memcache->get(session_id()) and there is data but when i return data (data is serialized array) it just keeps regenerate session id. In Laravel docs there is methods which explains how to implement it. But is it even possible to share sessions? I have 1 system where it uses native PHP BUT the session data is stored in memcache. Is it some sort of bug? I just dont understand why i cant just return data from my driver by giving session_id() (php function) because when i dump data there is data from memcache but when it is returned there is nothing.

Sorry for messy issue. I hope you got the point. If not please feel free to ask questions to provide more information.

Session middleware broken?

I'm using a fresh install of Lumen on Homestead. I've changed nothing but the app.php file where all I've done is uncommented
'Illuminate\Session\Middleware\StartSession',

After I've saved and try to visit the default route I get this error
Argument 1 passed to Illuminate\Session\Middleware\StartSession::addCookieToResponse() must be an instance of Symfony\Component\HttpFoundation\Response, string given
Looking further into the error I can see that it tries to give the addCookieToResponse Response argument the contents of the view file.
StartSession->addCookieToResponse('<html> <head> <title>Lumen</title>...., object(Store))

I'm not sure what is causing this problem but it seems to reside in the StartSession.php file inside the handle function.
$response = $next($request);

I hope is helpful to find and fix the problem, if there is one at all.

UrlGenerator asset

I'm trying to use app('url')->asset() in my view but i get these errors:
#1

ErrorException in UrlGenerator.php line 159:
Undefined property: Laravel\Lumen\Routing\UrlGenerator::$forceSchema (View: /home/agree/Documents/project/monitoring-pembelajaran/resources/views/layout.blade.php)

I fixed #1 by adding force schema property:
protected $forceSchema

But i get another error:
#2

ErrorException in UrlGenerator.php line 161:
Undefined property: Laravel\Lumen\Routing\UrlGenerator::$request (View: /home/agree/Documents/project/monitoring-pembelajaran/resources/views/layout.blade.php)

I fixed #2 by changing line 161 from this:
return $this->forceSchema ?: $this->request->getScheme().'://';

to this:
return $this->forceSchema ?: $this->app->make('request')->getScheme().'://';

Seems no further error.

Ability to configure log monog

Currently it defaults to writing to lumen.log, would be good if this is customizable out of the box. Would make it easier to use with services like heroku or with docker.

Request->route($param) doesnt work

trying to access route parameters through the request object (ie in controller constructor) doesnt work.

calling route() without any arguments works fine and returns an array (which i assume comes from fast route) however trying to get a param returns fatal error "parameter method doesnt exist on none object)

agreed fastroute isnt going to be as feature full as the beefy symfony alternative, but this should either be fixed or documented as not allowed.

Queueing mail

I have been having an issue with queuing mail. The docs mention having to add illuminate/mail to your composer.json but there are others to add.

My first error was missing SuperClosure. So I had to add jeremeamia/superclosure to my composer.json.

Now I am getting Fatal error: Call to a member function push() on null in C:\xampp\htdocs\vendor\illuminate\mail\Mailer.php on line 182. Someone on IRC thought maybe the illuminate/queue was missing so I tried adding it to composer.json. Nothing was downloaded or updated so It must have been there already.

This is my code

Form requests

Is there plans to add awesome Form Request from Laravel 5 to Lumen?

Lumen error as blank page.

I'm trying a fresh install with Lumen. Everything is fine except error page showing blank. No messages. Not even "Whoops, looks like something went wrong." .env file debug mode is true.

Please help!!

route() not including URL parameters - is it intended?

Hi!

First of all thank you for the great work with Lumen!

Having a route, e.g.:

$app->get('signin', ['as' => 'signin', 'uses' => 'App\Http\Controllers\SomeController@signIn']);

When using route('signin', ['username' => 'John']);, the string returned in Lumen 5.0.8 is http://mysite.com/signin without the username URL parameter. In Laravel 5, the returned value for the same route is http://mysite.com/signin?username=John

Is this a bug or intended functionality?

Lumen, dotenv and server environment variables

I've built a simple Lumen microservice which retrieves some data from database and sends the JSON-formatted results to client. Relevant characteristics:

  • Using the DB facade and am managing local database connection settings per usual in .env.
  • Uncommented Dotenv::load(__DIR__.'/../'); in bootstrap/app.php so .env settings can be loaded.
  • Copied vendor/laravel/lumen-framework/config/database.php into a newly created config directory.

This all works great locally, however when I deploy to Heroku I'm receiving the error:

PHP Fatal error:  Uncaught exception 'InvalidArgumentException' with 
message 'Dotenv: Environment file .env not found or not readable. Create 
file with your environment settings at /app/bootstrap/../.env' in 
/app/vendor/vlucas/phpdotenv/src/Dotenv.php:26 

Logically I don't want to use a .env file in production, preferring to instead using server environment variables. I've deployed several Laravel applications to Heroku in this fashion and the server environment variables are read by the dotenv library no problem, which makes this issue particularly confusing since I would presume this behavior would not change in Lumen after uncommenting Dotenv::load(__DIR__.'/../');

I'll keep digging but wanted to report this as something seems to be amiss (likely me).

Service container is not deferring call of boot methods on service providers

If I register service provider in bootstrap/app.php, boot method is called immediately after registration and not after registration of all service providers.

Is this intended behaviour? Because if it is so, then boot method on service provider doesn't make sense and I don't have mechanism to "decorate" services and I have to register service providers in right order.

Example:

// bootstrap/app.php
$app->register('QueryBusServiceProvider');
$app->register('AppServiceProvider');

// QueryBusServiceProvider.php

class QueryBusServiceProvider extends ServiceProvider
{
   public function register()
   {
      $this->app->singleton('QueryBus');
   }
}

// AppServiceProvider.php
class AppServiceProvider extends ServiceProvider
{
   public function boot()
   {
       $queryBus = $this->app->make('QueryBus');
       $queryBus->addExecutor($this->app->make('SomeService'));
   }
}

IOC not resolving $app in DatabaseManager

To replicate:

  • Fresh lumen install
  • Modify app/Http/routes.php to include the following:
use Illuminate\Database\DatabaseManager as DB;

$app->get('/', function(DB $db) {
    dd($db);
});

This is what I get:
Unresolvable dependency resolving [Parameter #0 [ <required> $app ]] in class Illuminate\Database\DatabaseManager

I realise I can use facades or app()->make('db'), but I would prefer not to.

@taylorotwell, am I missing something here? Do I need to bind $app myself?

Timezone issue

By default the timezone is UTC.
How can i change the lumen timezone?

Changing php configuration file does not help.

artisan key:generate

Consider as a feature enhancement putting artisan key:generate in Lumen and add to composer script as with Laravel 5

Extract Router to $app['router']

Some packages designed for Laravel use $app['router'] or app('router') to bind their routes (e.g. Intervention Image).

Currently these packages are mostly compatible with Lumen except routing definition.

I think extracting router to a separate class accessible through container (with passing through method calls like $app->get(...)) won't affect performance badly but increase compatibility of Laravel packages with Lumen.

And also this will allow to inject native Laravel router for those who want subdomain support #99

P.S. Faster routing is the best thing I like in Lumen

Error tests lumen

Try to run this test commented 'parent::tearDown();' and uncommented

Enabling withFacades does not enable all Facades

It seems there is a large number of Facades available to Lumen but there is no way of enabling many of them unless you modify the function withFacades. I think it would be better to be able to enable facades from bootstrap/app.php as this is advertised as the only place you need to configure.

UnitTest call(POST) response is not attended type

Hi,

The doc say that TestCase::call() returns an Illuminate\Http\Response.
It's the case when calling TestCase::call('GET')
But it's not the case with TestCase::call('POST'), which return a Symfony\Component\HttpFoundation\Response.

Cheers

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.