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.
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: https://github.com/ipfs/js-ipfs-api/issues/584#issuecomment-324287492
And we are even going to make it smaller with: https://github.com/ipfs/js-ipfs-api/issues/522 once https://github.com/ipfs/go-ipfs/issues/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 :)