-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a new "request-network-sdk" package that bundles all the packages for interacting with the protocol. #1181
Comments
Discovered package dependancy issues for @requestnetwork/payment-processor, when including it as a dependancy of the new SDK. Several of it's own dependancies (currency, smart-contracts, utils etc.) are not resolving, causing tsc build to fail. Requires investigation (ongoing). |
@skiv71 I made a comment on your PR that could explain your issues |
About point 2/, there might be an easy first step: Regarding the solution of a "SDK" package, I believe the name isn't appropriate. The requestNetwork SDK is a set of packages, what you want is an "umbrella" package, or starter for dapps. Some proposals: Having all dependencies installed "by default" would make installation slow (nb: it already is, but this is being worked on) and might cause dependency conflicts (version of ethers, of bn.js...). I definitely agree that we can improve the DX to get started with the SDK, but it's rather common to have more than 1 package to install to get started. Actually lots of libraries require this (for instance, this comes from the NestJS docs: |
I think we'll create new decryption mechanisms, starting with
I suppose. The "Request Network SDK" could be "all the packages in the monorepo" and the "Request Network dApp SDK"
@skiv71 was passionate that adding an umbrella package would be helpful for DX and convinced me that the effort was small and worth implementing sooner rather than later. If your argument is that it would have been better to wait on this task, I might agree, but at this point, we might as well continue. If you are against this change for a different reason, then please let me know. |
This task motivated a lot of good discussion between @skiv71 and me. We concluded that creating an umbrella package is not worth doing at the moment, despite the time spent so far. |
I previously closed it as completed, but it should have been closed as not planned. |
Problem(s)
Possible Solution
Create a new "request-network-sdk" package that bundles all of the packages that Builders typically install so that they only need to install 1 package to get all of the Request Network functionality in their app. The new package should be on the requestNetwork monorepo, not in a new repository.
What if they don't want ALL the functionality in their app?
We can tree-shake so the unused packages are removed from the final app.
We can't yet tree-shake so the unused modules within packages are removed from the final app. #1148 will add this ability to tree-shake at the module level.
The text was updated successfully, but these errors were encountered: