love this boilerplate, but why not develop it as a package?

[vesper8]

First of all, I wanna say I've been using this boilerplate in all my projects for over a year and absolutely love it. Am super excited about the upcoming v4 and am already using the development branch in my new projects.

Recently I have begun work on a huge and complex project and I decided to tackle it by developing a bunch of packages. This seems to be a popular way of doing things.. it really makes things modular.. allowing you to keep everything separate from controllers to models to migrations to views. Even for composer dependencies although they do all end up in the root vendor folder in the end. Only a few things need to be published.. notably assets.. configuration files and optionally views if users want to edit them. The Laravel 5.3 has some great docs on everything you can do and how easy it's become to keep things entirely separate and in its own package folder.

Currently I am using this boilerplate and building packages on top of it.. so it'll remain easy for me to install any updates you make. But it got me to thinking.. why isn't all of your stuff a package? To make it easy to install updates to the Laravel core.. and just to keep things as module and separate as possible.

Is this something you considered and then decided against? Or is there a reason why it doesn't really work in this case.

I'm still new to building with packages in mind so maybe I missed it.

I also suppose that by definition.. a boilerplate is different than a package.. but the result could be the same I think.

Keep up the great work!

A big fan

[digitalit]

I know @rappasoft has planes for module structure. This looks interesting for that: https://github.com/nWidart/laravel-modules

[vesper8]

I looked at that on github a few days ago and ultimately I decided I didn't need a tool to help me create packages/modules. I bought a Laravel Spark license and I know that Taylor initially developed Spark as a package that lived in the root folder, so I inspired myself with that knowing he'd be using best practices. That combined with a few tutorials on how to create packages which all essentially say the same as the 5.3 doc on packages. I just did it. Don't think you need an additional tool really. It wouldn't be very hard to turn this repo into a package. And the installation would be only a few steps.

Glad to hear @rappasoft is thinking about it

[digitalit]

I agree @vesper8, i too don't want the whole tool for managing modules just an basic structure that i can build on.

Although i don't want packages in vendor, i want the modules/packages to live in root.

Do you have any examples as how to achieve this?

[rappasoft]

The term boilerplate kind of implies its the whole deal, not a portion, which is why it's not a package.

I think it's a little big to be a package at this point, sure, the ACL and stuff could be extracted to a package, and probably should be, but I'm light on time.

Hopefully i'll have more time in the future to build on it, but right now i'm trying to keep it solid and the bare minimum (which is still a lot because this is a huge head start) so I don't have a lot to maintain on a daily basis.

You're guys PR's and issues keep my busy enough lol.

[vesper8]

@digitalit there's really nothing to it. https://laravel.com/docs/5.3/packages does a great job of explaining what you can do. I found this link useful as well https://devdojo.com/blog/tutorials/how-to-create-a-laravel-package

Your package should have the same type of folders as packages located in the vendor folder. You can basically take the folders located in your app/ folder and add them to /packages/mypackagename/src/ <-- here

Then in your composer.json file you add two things

"repositories": [
    { "type": "path", "url": "./packages/mypackagename" },
],

and

"require": {
    ...
    "myauthorname/mypackagename": "dev-master"
},

As long as you added that same name in your package's composer.json then this will cause your package's dependencies to also be installed (in the root /vendor) and will also autoload all your namespaces from inside your package

then just make your own service provider and add it to your /config/app.php

Or if you prefer, publish the provider first. The laravel doc explains all that

@rappasoft Great that you have in the back of your mind! I already am going to find it much easier to keep your boilerplate up to date by not mixing it with all of my own files now that I'm using packages. The only files that I can't blindly overwrite are the config/app.php and the composer.json. Everything else is now separated.

Like I said keep up the fine work! Looking forward to your release of v4!!

[digitalit]

To separate the BP and my stuff is also my goal. Do you have one package for each part like one for products, one for customers and so on or do you have all parts in one big package?

I haven't tried with this package way but with the module package i ran into problem with some translation issues where the trans method collided with the BP's trans.

As for the assets like the frontend i use an html5 template that lives in app/recourses/views/frontend and uses a lot of stuff from the public directory, how do you handle those?

Do you put everything like css js and all other template related in your package?

[vesper8]

@digitalit I don't work with translations yet but the 5.3 package docs do mention a word about translations

i keep all my views inside my packages and in my package service provider I use the loadViewsFrom to make them accessible throughout the app. I could publish the views to the main views folder and if I ever meant to allow others to use my packages then I would do it that way, as it stands I'm the only one using it so I keep them in one place and outside of the BP's views folder.

As for assets.. you have no choice but to publish those.. so I publish them from my package's resources/assets folder into the root public/vendor/mypackagename folder

I'm building a large app so I've actually set up 12 packages to make it very modular and keep everything separate. Might have gone a bit overkill but time will tell and I see no real cost to making things as modular as you can. Perhaps a performance cost will occur down the line.

[rappasoft]

The problem is we all do things differently, even if I were to somehow put all the BP stuff in one spot someone will still have a problem with it. I think its a good starting point and you don't really have to add every little commit I make (unless you want to) that's not a security risk or something. Most are just merging PR's or fixing issues other people have or want, if they don't apply you don't have to.

If I can extract the ACL to a package I will. As for the history, I think it works fine but everyone else seems to think otherwise, so I might remove it and use a third party history package so if it doesn't have something you want we can bug them and take more off my plate.

The reason I don't add in more features is for every feature I add to make it easier, it creates 10 more problems, or people argue over the way it should work or works.

I'm trying to find the time to keep up to date with Laravel since it changes every day, and to keep this up to date to keep everyone happy and building new things.

I'm just trying to find the happy medium of what to accomplish before releasing this release.

[digitalit]

After messing around with modules and packages i totally understand why you want to keep the BP very basic.

Just as you say i think many people will use the BP in totally different ways and to fill the BP with functions/packages will only make it harder to please everyone.

I for one have made so many tweaks to the BP and my functions differ a lot from the BP i terms om the total lack of Eloquent, i run only QB.

So my "BP" is for me the whole project. If i start an new customer site i don't start from an clean install, i simply copy the whole project with an new db from an dump file and then i do modifications to match the new customers needs.

[rappasoft]

I agree mine definitely differs from project to project. Do I wish it was more streamlined? Sure, but every project is so different.

[rappasoft]

I will keep all of this in mind but for now i'm going to close it to clean up the issue list to try to speed up launch of v4.