Suggestion: Document how to use local version of ipfs-http-client in a React app and have it pick up the local version of ipfs-utils as a child dep from the monorepo too

Help
1

I eventually got it working when using yarn with both the js-ipfs lerna monorepo and the React app, but it wasn’t clear how the combo of the lerna symlinks would work when using that in a different local app not in the js-ipfs lerna root dir.

2

Would you like to document what you had to do to get it working? The use-case sounds quite specific but it may help people searching this forum in future.

3

Sure will do.

Hmm, I’m not sure it’s all that specific. I would imagine that a React front end plus IPFS over HTTP might be the most common initial use case people try out?

4

I guess I’m not clear on why you would be cloning the whole repo as part of your project instead of just specifying react, ipfs and/or ipfs-http-client as deps of your project in the normal way, using them via require or import and not worrying about where they get ipfs-utils from?

The only time I can see this causing a problem is if you are working on ipfs itself and trying to debug it’s behaviour inside a react app.

Do you have an example repo with your setup?

5

Fair point, I did gloss over that - this would only be the approach once you’ve decided to debug something in the js-ipfs codebase or add a new features. I agree that people would start with installing the deps via npm or yarn. So the local clone of the js-ipfs monorepo only matters for a subset of people using IPFS over HTTP in React, but that’s still a pretty large swath of people beyond the IPFS core team. Especially now that js-ipfs is a monorepo, the odds of wanting to modify any of the ipfs packages in the js ecosystem add up since you’ll end up modifying the same repo for most of them.

I have an example repo of the React app, but unless you’re using a tool like Hugo Dias’ connect-deps rather than yarn link, your local symlinking setup isn’t captured by the state of the React repo, and the local js-ipfs repo will still be a separate repo. I suppose I could push both of them up and have them reference each other in their READMEs, but given the symlinking point I’m not sure it’s worth the trouble.

It’s simple enough to recreate from scratch: Clone js-ipfs, use create-react-app to make a new React app, add ipfs-http-client as a dep, but then use your preferred strategy to use your local version of the ipfs-http-client package instead.

6

So the local clone of the js-ipfs monorepo only matters for a subset of people using IPFS over HTTP in React, but that’s still a pretty large swath of people beyond the IPFS core team.

Only those doing active development on IPFS. If you’re just using it as a regular dep of your React project you shouldn’t be cloning or connect-depping anything, just use regular npm deps the same as before.

Especially now that js-ipfs is a monorepo, the odds of wanting to modify any of the ipfs packages in the js ecosystem add up since you’ll end up modifying the same repo for most of them.

The monorepo only contains ipfs, the http client and the interface tests (it previously contained ipfs-utils, this has been split out). We found that these repos were pretty much always changed together so them being able to be changed in one PR reduces the amount of work required to land a change.

The tooling may be lagging a little behind the curve, but it’s only a matter of time before @hugomrdias flips out and adds support for this use case to connect-deps.

1 Like