Answers: <blockquote>
    <ol>
    <li>What approaches are there to manage multiple package.json files that live in each feature directory</li>
    </ol>
  </blockquote>
  
  <p>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.</p>
  
  <blockquote>
    <ol start="2">
    <li>How do we identify common packages and lock them into a root /package.json file. (Independently, all developers already use yarn)</li>
    </ol>
  </blockquote>
  
  <p>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.</p>
  
  <blockquote>
    <ol start="3">
    <li>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?</li>
    </ol>
  </blockquote>
  
  <p>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 <code>DevOps handles the gritty bits</code> which is about silos and "throw it over the wall"</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-29T12:34:32.717Z
Answers: 2017-10-29T12:34:32.717Z
Answers: 030
Body: <p>We have a mono-laravel-repo and are in the process of migrating to a cleaner, easier to maintain dev reboot.</p>
  
  <p>We have recently moved towards migrating our existing PHP based views into multiple React-based "features" that live in a <code>/react</code> directory and are organised into <code>/react/featureName</code> sub-directories. This means Laravel's controllers mostly handle data and authentication only.</p>
  
  <p>Each feature is maintained by one or more developers, have their own dependencies, tests and functionality. </p>
  
  <p>We're currently serving builds in the public root of our project organised by feature:</p>
  
  <pre><code>js/FeatureName.hashed.js
  css/FeatureName.hased.css
  </code></pre>
  
  <p>which works great except that we share many packages between <code>features</code>. React itself, react-router etc.</p>
  
  <p>We intend to use Laravel's <code>mix.js</code> as much as possible, but hacking directly on <code>webpack.config</code> is also an option. </p>
  
  <p>I've explored the <code>mix.extract()</code> option that allows us to define <em>vendor.js</em> builds separate from other application logic but it stops there.</p>
  
  <p>So here are my question(s)</p>
  
  <ol>
  <li>What approaches are there to manage multiple <code>package.json</code> files that live in each feature directory</li>
  <li>How do we identify common packages and lock them into a root <code>/package.json</code> file. (Independently, all developers already use <code>yarn</code>)</li>
  <li>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?</li>
  </ol>
  
  <p>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.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-30T11:41:53.227Z
Comments: 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.
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2017-03-30T11:47:32.950Z
Comments: 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.
Comments: Dan Cornilescu
Tags: <configuration-management><configuration><monorepo>
Title: How to integrate multiple "feature" react apps into monolithic PHP repo?
UserDisplayName: Jason Joseph Nathan
ThreadText: # How to integrate multiple "feature" react apps into monolithic PHP repo?
  
  (Asked by: username_0 on 2017-03-30)
  
  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.
  
  **Tags:** configuration-management, configuration, monorepo
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_1**: 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.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-10-29. Score: 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.
  
  > 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"
  
  
  ---
  
  