Standardizing Widget Sharing
Custom widgets are fantastic! But the process to distribute your widget to the community right now is quite unintuitive, and there isn't currently a set standard for how widgets should be packaged or shared. As such, I want to propose a potential solution for sharing widgets across the community.
Publishing widgets to NPM
NPM (Node Package Manager) is the default package manager for Node.js, acting as the world's largest software registry for JavaScript and TypeScript. Node.js is already a required item in the install process for Experience Builder developer edition, meaning that all users will already have npm available. To give a brief description of the advantages of npm packages over static zip files, or GitHub repos: npm packages offer versioned, dependency-aware distribution — meaning consumers can pin to a specific version, receive patch updates automatically, and trust that all peer dependencies are resolved correctly. Unlike a zip file buried in a blog comment or a GitHub repo that requires manual cloning and building, an npm package is a single command away (With the Experience Builder CLI - Blog Post here), integrates directly into any standard build toolchain, and surfaces discoverability through the npm registry's search. Packages also carry a structured package.json manifest that declares compatibility, licensing, and entry points explicitly, eliminating the guesswork that comes with unstructured archives or repos.
Using NPM as the registry for custom widgets also ensures that your widget will continue to stay available long into the future, without relying on a post attachment staying intact, or a repo to continue to exist. This improves the widget usage process for everyone using widgets as well. Many users have to stick to a specific version of Developer Edition, so being able to regularly access a version specific for their installation would be a huge upgrade.
On top of being able to reliably publish widgets, if all widgets are published to npm using community standards (Described below) it will be incredibly easy to search for widgets, on a unified registry.
NPM Community Standards
- Prepend "exb-" to your widget name. For example, a widget named rightclick would be published to npm as exb-rightclick.
- Add exb-widget, experience-builder, and exb as keywords for your package.
- Use a license! Esri uses the Apache-2.0 license for most of their Experience Builder resources, and I like the MIT license. Do some research when deciding what license is best for you.
- Add a README.md file within the root directory of your widget. This is the best place to include documentation on use cases for the widget, who developed it, and any extra steps that a user might have to take to use the widget.
Using widgets published to NPM
Using npm commands to install widgets directly won't be the best solution, since the npm cli commands will download the widget to your node_modules folder, which is not helpful for actually using the widget within developer edition. Because of this, I have developed a command line interface, which uses the npm registry, but installs widgets in the way that Experience Builder would expect widgets. More information on the Experience Builder Community CLI can be found on my Esri Community post here, or on the npm page for the CLI here. The CLI also makes it easy to search for widgets published to npm, without having to find a blog post, GitHub repo, or anything else. Just search, and install, straight from the command line.
Comments
I truly think that npm makes the most sense for reliably publishing widgets. I recognize that this process hasn't been tried before, but I want to support the community in sharing resources across the GIS space, to make it easy for anyone to install developer edition, and have a rich library of widgets to extend the default functionality of Experience Builder, and build on top of what others have already created, instead of starting from scratch.
If you have any thoughts on this idea, positive or negative, please share them in the comments section below. I welcome feedback, and want to try to implement a solution that will work widely across the community.
