You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @SilentCicero! Really like what you demonstrated with this repo, it is true that some users might not need the whole js-ipfs-api bundle and therefore they can get a way reduced bundle size by just importing the functions they need.
With that in mind, @nunofmn went ahead and made js-ipfs-api modular, just like async or lodash, now you can require only the bundle you need with:
Would you consider focusing efforts in js-ipfs-api and keep doing work to make each submodular as smaller as possible? This would save a ton of work from updating two client libraries and would add a lot more test coverage.
Let me know what you think :)
The text was updated successfully, but these errors were encountered:
Hi @SilentCicero! Really like what you demonstrated with this repo, it is true that some users might not need the whole js-ipfs-api bundle and therefore they can get a way reduced bundle size by just importing the functions they need.
With that in mind, @nunofmn went ahead and made js-ipfs-api modular, just like async or lodash, now you can require only the bundle you need with:
Or even, just require a function of the set with:
This results in lot smaller bundle sizes, see the table: ipfs-inactive/js-ipfs-http-client#584 (comment)
And we are even going to make it smaller with: ipfs-inactive/js-ipfs-http-client#522 once ipfs/kubo#4008 is released in go-ipfs 0.4.11.
Would you consider focusing efforts in
js-ipfs-api
and keep doing work to make each submodular as smaller as possible? This would save a ton of work from updating two client libraries and would add a lot more test coverage.Let me know what you think :)
The text was updated successfully, but these errors were encountered: