creating and using a package or framework

[loud shale]

Basically I am looking for some input here.

Is it best building a website/app as a composer package and then just installing onto the framework or building in laravel itself.

Some background: the application is solely contained within itself there is no separate modules and or packages that need to be built

The package would include everything from modals, routes, views, authentication etc…

Its structure and functionally are depended t on laravel. The idea is it’s easier to keep it up to date with laravel

Is this a good or bad idea and why?

It’s been suggested to me that it’s better building everything as packages, I don’t see the benefit and I’m struggling to see anything online as building a full application with 100+ modals as a package

[peak crater]

Package is only better if you can build something generic enough to reuse across multiple applications.

[loud shale]

What about keeping everything up to date it was argued that building the full system as a package will be easier to keep updated as laravel does?

[peak crater]

That is not valid argument at all, and makes no sense. Not sure what you mean by this?

If a update for laravel comes out you would have to apply updates on both of the approaches you listed.

[loud shale]

I know what you mean I have been scratching my head for two days. I am against the idea but I am trying to be open minded and get more information but I am struggling to see why we would want to build the full system as one single package.

Is there any benefits to this? Or would be a worse approach?

[peak crater]

It makes no sense in your case. A full application as a package will still require the laravel framework as a dependency. So it makes no difference, all you are doing is moving the code from one repo to another.

[loud shale]

Well that’s what I thought… but was trying to get a different opinion it’s very bizarre to me to Evan try building a full application as a single package and I see no real benefit.

But… if there is no cons to it either it will make it hard to argue my case as they seem set to go down this route

[peak crater]

"Hey let me build a laravel application and then make another laravel application use this"
Not to be rude, but looks like the people that tell you this lack common sense. So if you did tell them some cons not sure it will make any difference.

Each time a change needs to be made you must require the parent app to do a composer update.
If you have CI jobs they will fail if devs dont push updated lock files, pointing to the correct branch (but dont forget merge conflicts). When you are working with multiple branches/features all of a sudden switching branches means you must do composer update again. Sure you can solve this by local repo linking, or through gitmodules, but what benefit do you gain.

[loud shale]

Very true this makes sense. We’ll time for me to try and argue my case a second time,

[peak crater]

And then when it comes to laravel upgrades you now have to perform an upgrade in 2 places. 🙂

Something changed in the config? Oh let me make sure the parent config is not overwriting the package config.

[loud shale]

Thanks for your input just wanted to hear another opinion

[loud shale]

@peak crater they decided to go with the package base aproach, they are building the full system as a package becouse they need to horizintly scale the application and when they need to theyll take certain parts out of that single package and make it there own contained pakage to be able to scale that part sepratly.

General Laravel Development
Generally, when you want to build a Laravel application you will do something like the following.

Create a new Laravel application by running laravel new project

Open your project in your IDE, and start building.

This is usually how people will create Laravel application, and generally how the documentation for Laravel tells you to create your app, however these is some drawbacks to this, and I will cover these here:

You are technically managing a full Laravel installation, meaning more code within your repository, and makes it harder to upgrade / update the framework.

Each time you build / package your application, your packaging Laravel alongside it, when you really don’t need too.

Each year when Laravel releases a new version, you will need to go through your codebase and upgrade the framework.

However, there is also some benefits to doing it this way:

Your directly following the main development process stated in the Laravel documentation.

You have complete control over the Laravel skeleton that is used in each build of your application.

Generally, out of the box, your IDE will lint and hint you with issues or imports.

With that being said, I will cover the Package based development method that we will be opting for, and why it is generally better in the enterprise environment to chose this method.

Package Based Laravel Development
When you create your Laravel application, usually you will need to install some extra packages, for example if you want to have automated code style fixes, you will install something like phpcsfixer or laravel-pint into your application, however lets say for example, we spin up a new Laravel application, and want to install XXXX, we can do this using packaged based development.

Some of the benefits from doing it this way are as follows:

You only maintain your own codebase, no need to maintain Laravel itself.

You can easily install using composer, meaning build processes are simpler and easier.

Your codebase is smaller, meaning storing artefacts and builds are more space saving.

With everything though, there are some downsides:

Development process is slightly more complex

IDE’s need to be setup to support package based development

Slightly harder to grasp the way you integrate into Laravel.

Thats the reasons given

[peak crater]

"This is usually how people will create Laravel application, and generally how the documentation for Laravel tells you to create your app, however these is some drawbacks to this, and I will cover these here:"

You are not doing anything different. Not worth my time replying. What you are doing is not package based development but do as you wish.

[loud shale]

this was the document that was left in regards as to why package based i was just seeing if you had a view onit. Its fine decision been made anyway i just struggle to visualize it

[peak crater]

Every point you make here has multiple counter arguments for your case. I would fire your tech lead mate.

[dense robin]

There's a lot of pros for package development, I really like how the main bits are inside it's own vendor folder, keeps the laravel core nice and lean.

Also I like the package namespace separation, and separate testing.