React monorepo package.json location

[JoeDravarol]

1. One package.json at the root of the project.

root
|
+-- ../              # existing files and folders
|
+-- client           # frontend related files and folder
|
+-- server           # backend related files and folder
|
+-- .eslintignore    # ignore files/folders that does not require linting
|
+-- .eslintrc.js     # linting configuration
|
+-- .perttierrc      # prettier configuration
|
+-- .package.json    # packages/dependencies for both client and server.

Pros

• Eslint and Prettier can be configured at one location
• Only have to run npm install in once place.
• Able to keep concurrently script to run client and server in one terminal.

Cons

• One package.json for both React and server dependencies. (I don't see this as a concened - a lot of React monorepo chooses this method).

2. An individual package.json within client and server folder.

root
|
+-- ../              # existing files and folders
|
+-- client           # frontend related files and folder
|
+-- server           # backend related files and folder

root/client
|
+-- ../              # existing files and folders
|
+-- .eslintignore    # ignore files/folders that does not require linting
|
+-- .eslintrc.js     # linting configuration
|
+-- .perttierrc      # prettier configuration
|
+-- .package.json    # packages/dependencies for client.

root/server
|
+-- ../              # existing files and folders
|
+-- .eslintignore    # ignore files/folders that does not require linting
|
+-- .eslintrc.js     # linting configuration
|
+-- .perttierrc      # prettier configuration
|
+-- .package.json    # packages/dependencies for server.

Pros

• Dependencies is seperated into their respected folders; e.g. React dependencies is inside of React package.json - server dependencies is inside of server package.json. (Separation of concern)
• Executing client and server will happen in separte terminal.
• Can host frontend and backend separately if necessary.

Cons

• We have to run npm install inside of client and sever folder. (Have to change directory. May not be intuitive for catch-up-crews helpers)
• Duplication of Eslint and Prettier configurations.
• Executing client and server will happen in separate terminal. (This will not be a concerned for some developers)

[Caleb-Cohen]

My vote is for one package.json. I prefer being able to install and start everything out of one terminal instead of two, and have not yet experienced any of the downsides.

@MatthewBozin and @WinstonHall, can you weigh in?

[ghost]

I'm of the personal opinion we should have separation. I can do either one, but based alone on my experience trying to make heads or tails of the original project folder I felt like the separation would have been nice. If the project was truly just a back-end content delivery service I would be into the singular source folder. However as it stands this project runs off of a rest back-end delivering content to the front-end. To me separating the two would be more readable to newer users, in the sense they could see specifically where what packages and libraries are being used. To really get down in the nitty gritty about all the reasons I would have to really have time to think before I speak though. I know why I dislike the idea but putting it into words that could relay my thought's is a bit tougher.

If we was to use a framework that unifies all the process's I would be a bigger proponent of the singular source of truth for a project folder/file structure. Again I'm open minded about this but smashing it all together (in my opinion) makes it less readable and harder to follow along with the what, where and why's of things being done.

[ghost]

Also to add something I left out, upon further re-reading the opening questions to the topic, I would think having two process's on one thread would make an issue logged in the terminal for one thing harder to discern, and you would have to run both things instead of being able to just run the front or back for smaller tests or implementations. Then there is the idea of hosting them on a platform, I just cant imagine running two things on one deployment as a singular thread. Unless of course we was using a framework that bundled those things up for us, and I'm relatively sure that those frameworks still split the front and back end apart behind the scene's.

[ghost]

To the linter part, would we not possibly run into issues with overlap. EX.(Something that would be linted in the back-end causing issues with something being done on the front-end that shares a similar structure getting picked up as wrong)? I don't know, I'm just posing the question for someone who might. I'm not the most versed on the finer details of linters, I kinda just bang the keyboard and make developer faces.

[Caleb-Cohen]

@WinstonHall I think we all agree that the file re-org was necessary and has drastically improved readability, thus becoming more accessible.

Where I'm getting caught up is how two terminals are more readable than one. I've found it easier to work out of one because I can get everything going with two commands and see all the console details in one terminal.

Can you, or anyone else, give me a real example that made the terminals more readable by having them split?

[ghost]

Lets just run it how you guys are for now. Partly its assumption based thinking, so I can't give you a certain answer. If we run into the issue I believe we will, then I can give an example lol.

[Caleb-Cohen]

Lets just run it how you guys are for now. Partly its assumption based thinking, so I can't give you a certain answer. If we run into the issue I believe we will, then I can give an example lol.

How would you rate the difficulty of splitting the terminal later in the project?

[ghost]

I wouldn't imagine it being difficult. For example I just ran both environments in separate terminals, as opposed to using the command to run the build.

[Caleb-Cohen]

@JoeDravarol Let's go with the one package.json for now. Are you able to open an issue?