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…
BoundingRectangle
Cartesian2/3
Cartographic
CesiumMath
Color
Ellipsoid
GeographicProjection
HeadingPitchRoll
Intersect
Matrix3/4
Quaternion
Rectangle
WebMercatorProjection
WebMercatorTilingScheme
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)?
3 Likes
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.
1 Like
Thanks all! A few thoughts:
Within Cesium, we have our own use cases for a more compact or minimal Core CesiumJS library, such as in GitHub - CesiumGS/gltf-pipeline: Content pipeline tools for optimizing glTF assets., where we depend on CesiumJS for utilities but don’t use it for rendering. (Which is then a dependency back in CesiumJS - gltf-pipeline as an npm module? · Issue #9614 · CesiumGS/cesium · GitHub)
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.
1 Like
Hello Gabby 
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.
1 Like
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.
1 Like
That’s great! If you need any help or want to get in touch with the Nx team somehow, please let me know 
1 Like
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.
1 Like
Hi all,
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!
3 Likes
Do you have a lightweight version released now
Hi @bloodwolf2020,
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.