-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feature: custom bundles #1144
Comments
I think a good way would be to move the ipfs core into a separate module (like |
What about allowing the core to be required out of |
I think that that would still include all the dependencies from the main bundle. |
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 |
Well, if core doesn't require any of the transports directly, then it won't be part of the bundle. |
Can we move from "believe" to "verified"? ipfs-api shouldn't be bundled as it is not required by anything in |
js-ipfs is being deprecated in favor of Helia. You can follow the migration plan here #4336 and read the migration guide. This issue has been resolved in Helia! if this does not address your concern please let us know by reopening this issue before 2023-06-05! |
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.
The text was updated successfully, but these errors were encountered: