Here's how I envision it. It has three main parts:
- The centralized registry of packages.
- The developer or developers who create and publish the package.
- The developer who will be using the package.
Scenario:
On a typical day, a developer is working on a form and realizes that a particular combo box should filter its options as the user types. The developer might know how to build this from scratch, or maybe not, but luckily there's a tool available within their environment that helps them integrate existing solutions.
What you as a user of packages will do:
First, the developer opens this tool, which presents a list of popular packages that can be imported. Somewhere in the tool, there's a search bar placed conveniently. The developer types something like 'combo box' or 'filter combo' into the search.
Next, the tool displays a list of packages that match the search criteria. Some example results might be:
- 'Combo Box Cascader' by MikeTools
- 'Filter Combo Boxes, List Boxes, Any List and More' by AlfredTheVBAMaster
- 'FAYT Filter Combos' by @MajP
- Other related packages
The developer can click on any of these options to view an overview of what the package does, but more importantly, how to use it. This helps the developer quickly decide if the package meets their needs before choosing to integrate it. The overview also includes useful details like the number of downloads, issue reports, developer reputation, and other indicators that help with the decision-making process.
Once the developer finds a suitable package, they can click to download it. At this point, the tool provides options based on how the developer wants to integrate it. For example, they might choose to:
- Import just the class module.
- Include a sample form.
- Add a sample database.
- Insert a few lines of code into a selected module to initialize the tool.
This makes it easy for the developer to customize the integration process and get up and running quickly without manually copying code or hunting through examples.
What a package developer will do:
Now, on the other side, the developer who makes the package should make sure to provide:
- A clear description of what the package does.
- A readme or usage guide with examples.
- Version numbers for each release.
- Information about dependencies, if any.
- A changelog explaining what's new in each version.
- Optional sample files like forms or sample databases.
- Metadata like author name, license type, and optionally a trust badge if the platform supports it.
- This makes it easier for others to understand what they're installing and how to use it right away.
We could use GitHub for some of these things.
The centralized registry:
Github could be used to store and serve all packages, their metadata, and any associated sample files, but we need an service to orchestrate the whole process. This other service should be able to:
- Provide an API or service that the tool uses to search, fetch package info, and download packages.
- Track download counts, version history, issue reports, and developer profiles. Same as above.
- Enforce publishing rules, like no duplicate package names, versioning, file size limits, etc.
- Support developer verification and trust scoring to help users identify reliable packages.
- Allow package removal or deprecation, that would be tricky, though.
This part is obviously the hardest, because we're not really sure if it's even going to be used and it requires a ton of development effort. However, we can create a light way version that does the minimal and see how well it is adopted, sort of like an MVP (Minimum Viable Product).