CODEWITHSUNDEEP
node.jsreactjsnpmisomorphic-javascript
JayC
JayC

Reputation: 2034

Organizing package.json dependencies in universal/isomorphic apps

With React and other frameworks it is now common to use npm and package.json to install the libraries you'll use on the frontend. If you are developing a universal/isomorphic app, this introduces the problem that the dependencies for the frontend and backend are stored in the same file, creating a massive dependency list.

If you use npm --save/--save-dev both types of dependencies (frontend, backend) become mixed and it's difficult to know, without going one by one, which one is used where.

Other than sorting and managing the dependency list by hand, is there any way to keep the list tidy? What are your strategies to manage dependency lists?

Upvotes: 7

Views: 1491

Answers (2)

Willem D'Haeseleer
Willem D'Haeseleer

Reputation: 20180

I strongly agree with sompylasar answer and want to expand a little further on it. I really do think two different package.json files is the only way to do this.

Think of your frontend and your backend as two different applications. In two very different environments as well, and as such your packaging and build chain needs will be different as well.

The whole point of npm is to have isolated dependencies per package. You are going against that by sharing your dependency list with two entirely unrelated applications ( frontend and backend ).

Imagine hiring new front end developers and they want to upgrade some front end packages, now they have to go ahead and figure out how to run and or test the backend as well because they might break something there.

It might feel like it's a little more cumbersome to manage two package.json files in the beginning, but this type of isolation will keep your app sane as it grows.

As such I would recommend a structure where you have two sibling folders with each their own package.json. Exactly how you want to structure that is up to you.

If you have core business logic you want to share between frontend and backend, then off course you can put that, in a separate npm package, which you can then reference in your backend and frontend package as a dependency. You can use npm link to develop against the same version simultaneously in your front and backend for development comfort.

Upvotes: 2

sompylasar
sompylasar

Reputation: 934

In a universal/isomorphic app, you'll probably have few dependencies that are purely frontend or purely backend; most of the dependencies are shared.

An option that comes to my mind is to use more than one package.json:

  • one for isomorphic dependencies (react, redux, etc.) and utility dependencies like the build system (babel, webpack, etc.), task runners (gulp, cross-env), testing (karma) and so on;
  • one for pure frontend dependencies;
  • one for pure backend dependencies.

I haven't used that structure myself, and I'm not sure that it will be more maintainable that a single package.json, because you'll have to manage more things (and if you add npm-shrinkwrap to that, it's twice as more files).

Upvotes: 2

Related Questions