feat: Provide access to bundled libraries when in browser

[vasco-santos]

In this PR, the bundled libraries mentioned in 406, as well as ipfs/js-ipfs#525 (comment) were added the same way as in js-ipfs-api.

For this issue, other 2 PRs were created

• js-ipfs-api
• interface-ipfs-core

[alanshaw]

Just wondering why these types are properties of an instance and not of the constructor/separate export?

[vasco-santos]

Hi @alanshaw

At first, I was thinking on a separate export, as you suggest. It is described here why the solution was the implemented.

[alanshaw]

hmm, I'm still not sure I understand the reasoning.

The util on js-ipfs-api instances contained functions that operate on the instance you've created - that makes sense. Putting non-instance related types/functions in an instance is a little odd. i.e. getting hold of CID: new IPFS().types.CID as opposed to const { CID } = IPFS.types.

Needless to say, if someone wanted to do something with CID before creating their IPFS node then they can't.

[vasco-santos]

I agree that it seems odd @alanshaw . However, if the js-ipfs is imported, I don't understand the point of not creating a node at first.

Anyway, I agree that it is a strange behavior and it should be improved. What do you suggest to support this, maintaining the coherency across repos?

[daviddias]

Let's get a decision on this asap to get both interfaces consistent. I'm fine with having these as static references (meaning, available through class and instance)

[daviddias]

I agree with @alanshaw. What about having both? @alanshaw wanna submit a separate PR to add the types as static exports too?

Meanwhile I'm coalescing this PR with #1319 so that we can finally get CI green again and work from a clean table.

[mitra42]

Did something stall this, I agree with @alanshaw that having this on static is significantly more useful, as we have code that doesn't easily have access to the ipfs node that makes this check by reimporting the "cids"