I'm developing a package for Laravel & Lumen in the same code base, but I encountered some problems.
Well, in the beginning, I thought it could have the same code and work for both frameworks, however it had!
But on the way of development it turned out; it didn’t work and I had to separate code into two branches.
As you can guess that's the main problem, I have to develop and fix bugs in two code base in two different worlds.
So I try to merge them. First of all, I removed tests dependency on the framework. Then, with some tricks I could remove Laravel and Lumen from composer.json and tried refactor code to use contracts or in the situations that is needed to use Illuminate packages by themselves.
Now I’m curious to know what was the best practice for my problem, should I write two packages using each one for one framework or there are any better ideas?
Therefore, I started searching on the internet and so far I couldn't found anything about writing one package for multi frameworks. (No guidelines)
Finally, here I am asking anyone that can help me to know more about my problem and give me a solution. (Any guides for how to write a package for two frameworks).
Thanks for your time.
P.S:
I have multiple services both in Laravel and Lumen, so I need a code to care about publish and consume events between services.
For more clarify I need something to deal with RabbitMQ Publish/Subscribe.
-
2Currently, it is hard to understand how dependent/independent your package from the specific framework is. Can you edit your question and give a short outline of its purpose and an example where you run into trouble keeping it in one branch?– Doc BrownDec 20, 2020 at 18:04
-
1In principle, you should be able to formulate the "core" of your package in a framework-independent way, then write thin, framework-dependent wrappers ("glue code") for each framework, so that your "core" code is shared (there may be a lot of glue code, but the important changes that you don't want made in two places should now pertain mostly to this core). In practice, depending on the nature of the problem your code is solving, and how constraining the frameworks are, there may be difficulties, but generally, that's how you'd go about it.– Filip MilovanovićDec 20, 2020 at 18:04
1 Answer
Now I’m curious to know what was the best practice for my problem, should I write two packages using each one for one framework or there are any better ideas?
If you mean having two packages consisting of the same logic, then no, you should not have something like this. Because then you will likely end in the maintenance hell as you already noticed. Nobody wants to write things twice.
Thumb rule: Core business functionality should never depend of any framework specific stuff. The result will be otherwise that, what you experience now. If you calculate a tax rate, the tax rate should behave in Laravel the same as in Lumen. Instead let your framework using your business code through a predefined API.
Normally you will have some kind of thin layer on top, that is responsible for connecting framework specific to your core business functionality.
This requires consequent programming in every aspect, like including own models in your packages etc.
I personally would try to split the application up into different small packages which each care for only one responsibility. All of these small packages will then communicate with each other also through predefined APIs. You will notice, when you sliced it small enough, that you can swap packages by existing ones.
Think for example of a car that represents your application. If one wheel getting too small in the meantime while you build your car but its inseparable connected to the engine, you cant just replace the wheel. You would have to remove the engine also (or at least you must be very rude to disconnect it from the engine). While when its not coupled tight you just remove four screws and go with a new tire. Also: You will find hundreds of tire manufacturer you can choose your favoorite tire from. But you will obviously not find a manufacturer that produces tires connected with a whole engine on it.
