Hi — this is a very interesting looking project, and I suppose my issue is a bit of a meta-comment, related to #3.
The structure of the project (a fork the base Mapbox-GL JS codebase) seems to get in the way of its continued usability and maintainability. It's hard to get a sense as a potential user/outside contributor as to what parts have been changed from the base Mapbox codebase.
Is it feasible to restructure this project as a module with a dependency on Mapbox GL? Even if it uses non-public APIs, keeping the codebases separate would be a major win, even if the Mapbox GL version has to be pinned or included as a submodule. It would make it much more tractable for the purposes of external contributions. Relatedly, changing the module ID could allow this and the first-party Mapbox GL to exist side-by-side in the same codebase, if needed.
Hi — this is a very interesting looking project, and I suppose my issue is a bit of a meta-comment, related to #3.
The structure of the project (a fork the base Mapbox-GL JS codebase) seems to get in the way of its continued usability and maintainability. It's hard to get a sense as a potential user/outside contributor as to what parts have been changed from the base Mapbox codebase.
Is it feasible to restructure this project as a module with a dependency on Mapbox GL? Even if it uses non-public APIs, keeping the codebases separate would be a major win, even if the Mapbox GL version has to be pinned or included as a submodule. It would make it much more tractable for the purposes of external contributions. Relatedly, changing the module ID could allow this and the first-party Mapbox GL to exist side-by-side in the same codebase, if needed.