How to integrate multiple "feature" react apps into monolithic PHP repo?

Question

We have a mono-laravel-repo and are in the process of migrating to a cleaner, easier to maintain dev reboot.

We have recently moved towards migrating our existing PHP based views into multiple React-based "features" that live in a /react directory and are organised into /react/featureName sub-directories. This means Laravel's controllers mostly handle data and authentication only.

Each feature is maintained by one or more developers, have their own dependencies, tests and functionality.

We're currently serving builds in the public root of our project organised by feature:

js/FeatureName.hashed.js
css/FeatureName.hased.css

which works great except that we share many packages between features. React itself, react-router etc.

We intend to use Laravel's mix.js as much as possible, but hacking directly on webpack.config is also an option.

I've explored the mix.extract() option that allows us to define vendor.js builds separate from other application logic but it stops there.

So here are my question(s)

1. What approaches are there to manage multiple package.json files that live in each feature directory
2. How do we identify common packages and lock them into a root /package.json file. (Independently, all developers already use yarn)
3. How to accomplish this with as little friction as possible for all react based developers - so that they get to simply continue with whatever they are already doing and DevOps handles the gritty bits?

I understand there might be a need for more information, please shout out what you need in the comments and I'd be happy to update the question.

Answer 1

1. What approaches are there to manage multiple package.json files that live in each feature directory

One could leave the package.json in every feature directory and let the CI read the package.json when building the app. One could define the versions of dependencies in the package.json to get control about the app. If the app works with version A.B.C of a certain library then one could define this version to prevent that an update will break the app.

2. How do we identify common packages and lock them into a root /package.json file. (Independently, all developers already use yarn)

Discuss this with the team and figure out what is the best solution for everybody. Multiple solutions are possible. Everybody should be happy with a certain approach.

3. How to accomplish this with as little friction as possible for all react based developers - so that they get to simply continue with whatever they are already doing and DevOps handles the gritty bits?

DevOps in my opinion means that a certain team that consists of multiple specialties, e.g. test, dev, ops is responsible for a certain app. This means that the whole team should agree with a certain approach and everybody should work and handle issues according that process instead of DevOps handles the gritty bits which is about silos and "throw it over the wall"