Pros and Cons of 2 package.json files in a Rails plus React rails/webpacker project

Rails react_on_rails
1

Option 1: Standard Rails – Only a top-level package.json

  • Pros
    • Matches the current standard for rails/webpacker
  • Cons
    • Misses out on the pros of option 2

Option 2: Isolated Client Directory – Having both a top-level package.json and a child one in /client

  • Pros
    • Easier to open up the /client directory in a JS editor.
    • Project organization is a bit more clear with all client files in one directory, including webpack configuration.
    • Slightly easier for front-end developers to grok the front-end parts.
  • Cons
    • Need to remember to cd client && yarn for developers
    • Need to add "scripts": { "heroku-postbuild": "cd ./client && yarn" }, so Heroku knows what to do.

Overall, I don’t see a huge difference either way.

In ShakaCode’s package.json for Hawaii Chee, we’ve got this, shown below. Given that there are only 2 dependency packages of this, merging in the lower package.json would be relatively minor.

{
  "engines": {
    "node": "12.13.1",
    "yarn": "1.19.2"
  },
  "scripts": {
    "heroku-postbuild": "cd ./client && yarn"
  },
  "dependencies": {
    "mjml": "4.5.1"
  },
  "devDependencies": {
    "cypress": "^3.1.5"
  },
  "optionalDependencies": {
    "fsevents": "^1.2.7"
  }
}