As an active member of our vibrant community, I have been deeply involved in developing various Motoko libraries over the years. Through my experiences, I have encountered challenges in maintaining the libraries’ dependencies on one another, which has often caused difficulties in keeping them up to date.
To address this issue and streamline the development process, I propose the bundling of all Aviate Labs’ Motoko libraries into a comprehensive package. This collective package would consolidate all existing libraries into a single cohesive unit, facilitating easier management and minimizing the burden of maintaining individual dependencies.
Benefits of Bundling Motoko Libraries:
Simplified Dependency Management: By bundling all libraries together, we eliminate the need for individual library updates and ensure consistent compatibility across the entire package. This greatly simplifies the process of managing and resolving inter-library dependencies.
Increased Development Efficiency: With a unified library package, developers can access a comprehensive suite of functionalities without the hassle of searching for and integrating multiple libraries.
Enhanced Codebase Integrity: Consolidating libraries into a single package helps maintain code consistency and integrity. Updates and bug fixes can be applied uniformly, reducing the risk of inconsistencies or conflicts that may arise when using separate libraries.
Improved Documentation and Support: A bundled library package allows for centralized documentation and support resources. This makes it easier for both newcomers and experienced developers to find relevant information, seek assistance, and contribute to the collective knowledge base.
Feedback and Discussion: I would greatly appreciate your thoughts and feedback on this proposal. I encourage you to participate in the discussion, where we can collectively explore the potential benefits, challenges, and concerns associated with bundling Motoko libraries into a single package.
Let us seize this opportunity to enhance our development ecosystem, promote collaboration, and empower Motoko developers to create even more powerful and robust applications. Your input and engagement are crucial to shaping the future of Motoko libraries.
Thank you for your attention, and I look forward to hearing your valuable perspectives.
Generally, this sounds great to me. But I do not see any drawbacks listed, so allow me to propose a few (potential) drawbacks:
Discoverability. Comparing to rust, if I want a date library I search the index for date. If I am looking for a hash function I can search for e.g. sha2. Both of these give me reasonable starting points just from the library names.
Download size. Not a concern for many of us, but I know that some people have pretty bad connections
Build time. More code in a library = more stuff to build. Not sure how bad the impact is on that one
Binary size. No idea about this one either, but there could be an impact in both directions
First of all, thank you and Aviate Labs for all the libraries. They are very helpful.
I like the idea of bundling them very much. I was hoping you do that.
The way Motoko base is set seems to be pretty convenient. All packages are in one folder
and you can quickly hop from file to file and see what’s going on.
Otherwise, you have to go to Github, search repo, pick version, browse folders, just to find that one file you need to look at.
Also, it would make things easier for contributors. I could just clone the whole repo and work with that
instead of using the package manager. Then instead of having 3 Array libraries with different functions each (One base, one yours, one mine), I will probably have only 2 and put my additions inside your lib.
Discoverability is indeed a significant downside when it comes to the proposed approach. Having descriptive library names and a well-indexed search system, like in Rust, greatly aids developers in finding the libraries they need.
As for build and binary size, it would be ideal if the compiler could optimize and reduce these sizes automatically. This would alleviate concerns related to longer build times and larger binaries. However, the extent of the impact on build time and binary size will depend on the specific implementation and the amount of code added from libraries.
Some additional possible drawbacks of bundling Motoko libraries into a single package:
Increased Complexity: Bundling multiple libraries into a single package can result in a more complex codebase. It may require additional effort to understand and navigate the bundled package, especially for new developers joining the project.
Limited Customization: Bundling libraries together may restrict developers’ ability to choose specific versions or components of individual libraries. This limitation could be problematic if a developer wants to use a specific feature or functionality from a particular library that is not included in the bundled package.
Larger Package Size: Combining multiple libraries into a single package can lead to a larger overall package size. This may impact application performance and increase deployment and download times, especially in scenarios with limited bandwidth or resource-constrained environments.
Slower Library Updates: Bundling libraries together can slow down the release and update cycles of individual libraries. Updates or bug fixes to a specific library may need to wait for the next bundled package release, potentially delaying critical patches or improvements.
It is important to carefully consider these drawbacks alongside the proposed benefits and evaluate whether the bundling approach aligns with the goals and requirements of the community.
That sounds sensible to me. Increasing the package size shouldn’t affect compile times since Motoko only pulls in the libraries it needs when compiling, not the entire package sources.
and put my additions inside your lib.