OpenStreetMap
There’s long been a desire & incoming wish for iD to be modular. Modular is a pretty general term, so I’ll narrow it down into three general goals:
- Modules as a way of building a system. Using rollup, browserify, etc., in order to structure code and separate internal components in a nice, predictable way.
- Modules as a way of letting other systems include yours. Generally, in JavaScript-land, means publishing to npm.
- Modules as ways to include new code in your project. This is more in the vein of iD plugins. Supporting plugins would let us support contentious or rare needs without bikeshedding their inclusion to the main project.
With the help of Bryan, Kushan, David, Beau and Martin, we’ve made significant progress toward the first goal and are nearly at the finish line. iD will be switching from a system where we concatenate source files and use GNU make as a build process - to one that uses rollupjs to build a bundle from JavaScript modules. The expected benefits are big, for maintainers:
- iD no longer relies on the global namespace for dependencies like d3, so there’s less chance for conflict.
- misnamed requires or invalid requires will be caught early
- we can use npm modules for our dependencies, rather than keeping them in the project’s source tree
- we’ll be able to build a faster and more reliable environment for development
- we’re upgrading d3 to v4, keeping it in line with the changing software world.
This doesn’t immediately win us (2) and (3) but it pulls them closer. Soon, a new editor could reuse iD’s data model, and iD could load new functionality from a plugin.
And there likely won’t be any user-facing change as part of this port. This is the stage where the developers throw tens of hours into the low-level guts so that plugins can be possible and long-term maintenance can be less painful.
