Adding Laravlel's generators to Lumen

Hey!

As far as I understand the best strategy is to develop your API as a classical Laravel application and once you are ready move models, controllers and other source to Lumen and toy around to enable all you actually need and then deploy.

I could be wrong (I am new to Laravel and Lumen), but I don't get it either, nor does the suggested best strategy sound like a good strategy at all. Something is very wrong when it is easier to develop a Lumen application in Laravel and copy+paste back to Lumen due to the gained efficiencies of generators.

I also don't see any valid argument for increased overhead, it is not like the generators are used in production and surely the cost of requiring the dependencies whether locally or in production is trivial compared to the efficiencies gained.

I'm hopeful to be proved wrong or someone more familiar with Lumen/Laravel putting together a package which would make the process of development in Lumen as breezy as 5.1.

Lumen was actually a micro framework Taylor developed foe Envoyer to ping servers and store that data. Have a listen to the Laravel podcasts (google it) and he explains why.

It has been mentioned many times in old posts, it intended to be light weight and fast not for a full app. If it's lacking features us Laravel. You need something that runs fast and/or just handle a particular task use lumen.

I have a couple lumen apps that run scheduled tasks to create reports on a scheduled command that is to resource intensive for the main app and server. Works amazingly well.

Let me preface this by saying that I am a complete noob to both Laravel and Lumen, and I wish I was in a position to contribute instead of pointing the finger but alas, i'm not there yet!

I understand that Lumen != Laravel, however I don't understand why some of the dev tools like generators and tinker were omitted, especially because Lumen is designed to rapidly extract micro services from larger applications (perhaps in many cases, non-Laravel applications).

I would argue in the case of tinker and generators, they are "dev tools" rather than "full stack" components so I think they should be given special consideration for inclusion by Taylor.

Without knowing about the dependencies and intricacies of those tools, my assumption is they would have zero to low impact on production speed, but have a very positive impact on developers getting stuff done.

I would have thought that is a great reason to include those features whilst still omitting the vast swathe of core Laravel.