Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

SilvaDreamdeal's avatar

Laravel Modules

I have a project that is being very big I started to look around for better ways to work, because we will divide the project in modules.

I found nwidart.com Dividing the project into multiple modules is exactly what we want

But, if my application has 2 modules (A and B) and for one element of the team I just want to give access to the B module. Its the only one that he can see, change, update and test

Am I able to do that?

We have the app in Gitlab Right now the Programmer can get the full project code, run locally and change all code

Now we will have 2 programmers. I just want to give access for module B and/or to create other modules. But he can never edit module A. He still needs to get the full project to run the app?

Is this the best way to divide a big application or is there another option? I mean, if a project has 20 modules, what is the best way to divide responsabilities?

Module A, B, C to programmer A (just this programmer can update), etc...? Because, maybe I have sensitive information that I only truste Programmer A to look and change if needed, and never want that to other programmer (whatever info it is, just imagine)

Maybe I'm not telling correctly the problem or I'm being a little confused, and sorry about that. I'm just looking for a good way to divide this

0 likes
8 replies
martinbean's avatar

But, if my application has 2 modules (A and B). But for one element of the team I just want to give access to the B module. Its the only one that he can see, change, update and test

@silvadreamdeal If a developer has access to your repository, then they can view the code from all of it. You can’t arbitrarily give them access to specific directories only.

If you’re using GitHub, you can use a CODEOWNERS file to determine what paths users should be able to update. Any modifications to files with a code owner will require a review from one of those owners.

So for example, if someone typically working on code in Module B makes a change to code in Module A, then a code owner from Module A would need to approve the change before it was merged into your main branch.

1 like
SilvaDreamdeal's avatar

@martinbean thanks for the reply. I dont have any problem if the programmer sees the Module A code. I just dont want him to make changes

It seems that what you are suggesting is a good option. Because I can limit where the programmer can do updates

1 like
martinbean's avatar
martinbean
2 years ago
Best Answer
Level 80

@SilvaDreamdeal Yeah. We use CODEOWNERS files a lot at work. It’s good at enforcing a review if a developer is changing code that they shouldn’t really need to change, or shouldn’t be allowed to at all.

For example, we use GitHub Actions for CI and CD. But the workflow scripts themselves are restricted to the DevOps team. So developers can’t change workflows to say, reduce the test coverage percentage if their PR is failing to meet the required threshold.

We also have a massive documentation portal for multiple platform teams, so changes to platform-specific documentation needs to be approved by a team owner from that team. Someone from Team A can’t just go and start updating Team B’s documentation pages.

2 likes
SilvaDreamdeal's avatar

@martinbean honestly I think we will discuss this method and thinking about to adopt it

We have a small team, but honestly we have a product that is growing fast and big. We need to start to think a step forward. Everything organized. Because if its not well organized, the future will be chaotic

I didnt think about that documentation step. Its a good idea. We have all documented to, but thats a good point. Its not just a point of code but documentation needs to be considered to. Thanks for the help. I will start to do some basic Module Apps, just to see how it works in order to present that to the company

1 like
anddre's avatar

I went through the same problem and what you need to start with is the nwidart package and take a look on git submodules, in this case I created a .gitmodules on root of my project and you need to declare your module's link there, don't forget to put the configuration of ignore submodule files to avoid versioning. now about permissions I use GitHub and there I can tell which group will have access to module x or y.

Doesn't forget to put the . gitmodules on .gitignore also because when you update your project with git for each you get the project git url at first configuration.

1 like

Please or to participate in this conversation.