propose: js projects configuration #82
Conversation
vasco-santos
force-pushed
the
vasco-santos/js-configuration
branch
from
377fea4 to
665c7b6
Compare
| #### What does done look like? | ||
| _What specific deliverables should completed to consider this project done?_ | ||
|
|
||
| TODO, we need to define the scope |
There was a problem hiding this comment.
Perhaps we can deal with the scoping challenge by limiting it to the libp2p work as round-1 to form stronger opinions about how to do this well and then do subsequent iterations/projects doing that elsewhere. The proposal in libp2p/js-libp2p#576 (comment) looks like a pretty solid suggestion for how to move forward and we could just adopt that as the basis of a plan (with updates to account for newer perspectives).
There's probably some overlap with #71 and some of the work we did in multiformats/ipld (e.g. see https://github.com/multiformats/js-multiformats/blob/master/src/basics.js for a "give me the common basics" version vs the "I'll build my own, thanks"). I imagine there's opportunities here to decouple code paths so that, in configuring your libp2p you're instantiating a set of dependent modules (& packages) that can be easily tree-shaken by a bundler.
There was a problem hiding this comment.
I think limiting to libp2p initially would be beneficial, it's the most challenging to configure at this point. A possible amendment, although it could be done as a followup, would be to setup deployment to automatically release the various configurations as ready to go libp2p modules, similar to https://github.com/carsonfarmer/libp2p-bundle, which would reduce the need to install any other modules to get up and running. The multiformats/ipld work is a great reference for potential structure here. If we built this out, we could later go through crypto and shake out the needed components for each of these bundles, namely browsers, to reduce size for those configs.
There was a problem hiding this comment.
I agree with decoupling this into libp2p first as I think that is where most of the pain points are.
However, there are some issues on ipfs configuration "conflicts" with libp2p per ipfs/js-ipfs#3590 (comment), where we have multiple ways of configure things and then surprising end results might appear. This can probably be a maintenance task in ipfs or something that the onboarding team can have a look. What do you think?
There was a problem hiding this comment.
This can probably be a maintenance task in ipfs
That or it could eventually become a project. To keep the scope small here, starting with making libp2p easy to construct and then have a default build for Node.js and the browser that can be used on the public network out of the box would be a good starting point. This gets immediate value to new users so they can avoid configuration, and makes it easier for us to roll these changes into js-ipfs and improve its configuration later.
|
Closing this as it is not on our immediate roadmap. We will reopen when this work intersects with our future timelines and priorities. |
This project aims at improving the JS projects configuration, which has been one of the biggest barriers for users to get up to speed in our stack. The challenge here is defining the scope or decoupling this project into multiple sub-projects. I have a big context on the libp2p side of things, but would like to get input from other folks to include the remaining projects.