7

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.

  • I'd suggest to keep the most important question on this post and ask the other ones on separate posts, eventually referring to this post to not repeat the details. – Dan Cornilescu Mar 30 '17 at 11:41
  • I'd also suggest dropping the "Best way" in the question - it makes the question opinion-based, which is frowned upon. How about replacing it with just "How"? If you may get multiple answers, the number of votes will indicate which is the most popular, you indicate which one was best for you by accepting one of them. – Dan Cornilescu Mar 30 '17 at 11:47
2
  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.

  1. 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.

  1. 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"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.