feature: custom bundles

[pgte]

On apps that use js-ipfs I never use the HTTP API, but I believe that the ipfs-api code always ends up in the bundle.

The same thing applies to some transports. For instance, I would like to have a bundle that does not include the Websocket or the WebRTC-Star transports.

In my case, the same applies to some IPFS features like DHT or the object API.

I would love to have the possibility of creating a custom js-ipfs bundle that does not contain code for features I don't intend to use.

[mkg20001]

I think a good way would be to move the ipfs core into a separate module (likejs-ipfs-core) and to make js-ipfs be the main bundle that contains all the transports, etc. so other bundles could be built upon js-ipfs-core without including all the transports, etc. in the other bundle

[RangerMauve]

What about allowing the core to be required out of ipfs/core?

[mkg20001]

What about allowing the core to be required out of ipfs/core?

I think that that would still include all the dependencies from the main bundle.

[victorb]

Should we not aim to make the code easily optimized with existing tools like uglify and tree-shaking rather than spending efforts modularizing everything? Even if we modularize everything, dead-code elimination would remove more code from the bundle than we could do when creating multiple modules.

Remember, we used to do this with libp2p bundles, but in the end put them together as they were not very heavily used separately.

Although, I agree that the HTTP API/Gateway should not be bundled by default, but rather a separate module that would include js-ipfs.

[RangerMauve]

Well, if core doesn't require any of the transports directly, then it won't be part of the bundle.

[daviddias]

On apps that use js-ipfs I never use the HTTP API, but I believe that the ipfs-api code always ends up in the bundle.

Can we move from "believe" to "verified"? ipfs-api shouldn't be bundled as it is not required by anything in src/core