At Propeller we’ve found that the battle tested Cesium math classes can be useful for various applications outside of a Cesium viewer. e.g. NodeJS server side computation and rendering, in-house libraries that require some vector math etc. Pulling in Cesium as a dependency can be reasonably heavy (currently 90MB) which inevitably provides a lot of functionality that remains unused. It also ties in to the monthly Cesium versioning, where the core math classes in practice change infrequently.
To address this, and to help in space constrained environments (like AWS Lambda) we have developed an in-house compact library that is a drop in replacement for a subset of Cesium functionality and uses semantic versioning. At the moment it is already useful in providing functionality like…
Is this problem unique to us? Is anyone else doing similar? What is the level of interest in some sort of solution either managed by the Cesium team as part of the CesiumJS project, or open sourced by a 3rd party (e.g. Propeller)?
Although I’m not so deeply involved in CesiumJS or applications that could find parts of CesiumJS useful, I have one very high level comment:
If CesiumJS is split into multiple parts, then one could at least consider to align this with GitHub - CesiumGS/cesium-native . This does not mean that the mapping between “classes” and “libraries” has to match perfectly in both environments. But I think that from the perspective of consistency, documentation, and discoverability, it could be good to at least have similar “concepts” or “domains” being covered with these libraries.
As such, most of the classes from the list above would fit into some CesiumMath- or CesiumGeometry library, but some of them could reasonably be moved into a CesiumGeospatial library. The latter would likely depend on one of both of the former, but would only be required by applications that want to do more than pure vector math.
CesiumJS is already pretty modular, and having smaller cohesive modules is usually a best practice. So I don’t think there are many concerns from an architecture perspective.
If we were to introduce a solution like this, we would need to make sure it does not introduce an additional maintenance burden. For instance, it’s common to make changes to Core classes and non-Core class simultaneously in PRs, and we want to make sure there’s not more developer overhead to do so. As such, we would most likely want to maintain multiple modules from one “monorepo”.
Popular projects like Bablyon.js, Babel, React, and Angular all maintain a monorepo which publishes several packages with lerna.
If you are thinking to embrace a monorepo approach to the Cesium architecture at some point, you should check out Nx, one of the best monorepo implementations currently that also took stewardship of Lerna.
Awesome, thanks @Aristeidis_Bampakos! Nx looks like a powerful tool and may be a path to investigate further if we do go all in on the monorepo approach. It looks like we could migrate after setting up lerna, and would be able integrate with existing dev tools.
I’d love to see this, our current non-browser / non-visual approach is a hotch-potch of libraries and own code that we had to put together in fear of having to use the whole package in every little project, which is a shame as a lot of the Cesium code is really fast and good. +1 from us at 4DMapper. Happy to help out with whatever is needed.
We’ve been planning out an initial implementation of smaller npm modules with npm workspaces, starting by splitting off Widgets into their own package. We chose to start with Widgets since its a clear architectural delineation, is not needed by many web apps, and brings in dependencies which can be problematic for some projects. The idea is that we can then further break out smaller packages, like Core, later using a similar structure.
Please comment in that issue to let us know if you have any thoughts!
We have split out the Widgets layer, which contains mainly UI and widget related code such as the Viewer, Timeline, geocoder, etc. So we ship two smaller packages: @cesium/widgets, and @cesium/engine, which contains everything else.
We would like to further separate @cesium/engine into smaller distributions in the future. For instance a Core library or a 3D Tiles loading library.
A small “bump” for others stumbling over this thread:
A first step of this is part of CesiumJS 1.146. The new core package contains base classes like Cartesian2/3/4, Matrix3/4, and Quaternion.
One could brainstorm about further splits here - maybe something like a base package for fundamental things like defined or clone, or a temporal package for all the calendar/date/time related functions, or an actual math package that only contains the Cartesian/Matrix/... classes.
But one important point is already achieved with the core package. There is that "dependencies": {} in the package JSON of this package.
It may look subtle at the first glance, but it is very important: It means that this package is really standalone and can be pulled into other projects, as a dependency, without having to be concerned about hundreds of files (and megabytes) being pulled into the node_modules directory.
