Replies: 1 comment 3 replies
-
Yeah, these standards have started to come about recently. They were less known when we started the journey of this project. I'm not against the idea of tidying it up to keep it inline. We have always tried to follow the "Laravel way" of doing things. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I believe that both the Laravel Framework and Filament packages uses a similar style for their code structure and naming conventions, and are very well structured and easy to understand and get into.
For example placing
interfaces
in aContracts
folder1, andtraits
in aConcerns
folder2.Lunar places a
xInterface.php
next to the default class implementation3, andtraits
in aTraits
folder4. And sometimes without the Interface suffix5.Looking in to it more, Laravel actually seems to place some of their interfaces like you do6, next to the default implementation. Though, most that are supposed to be used in userland are still placed in a top
Contracts
folder7. (I think…)I'm also a big fan of Filament because of everything being typed. It really helps the IDE understand the codebase easily.
What are your thoughts about aligning the Lunar codebase with these conventions, to make it feel intuitive and integrated for newcomers?
Note
I haven't looked very much into the Lunar codebase — yet — so please don't take this as critique. I'm just curious about what your thoughs and plans are. 😊
Footnotes
Filament placing
interfaces
in aContracts
folder ↩Filament placing
traits
in aConcerns
folder ↩Lunar placing
xInterface.php
next to default class implementation ↩Lunar placing
traits
in aTraits
folder ↩Lunar naming TaxDriver
interface
without suffix ↩Laravel
xInterface.php
next to default class implementation ↩Laravel placing
interfaces
in a topContracts
folder ↩Beta Was this translation helpful? Give feedback.
All reactions