There were a few areas in Source where a function was assumed to be executed synchronously when a function was resolved. Native Promises however, by spec, will resolve at the end of a frame. There were also some strange handling of promise rejection in imagery providers that I cleaned up a bit in order to make them testable.
- In LabelCollection and EntityCluster, order of execution adjustment where made.
- Added TextureAtlas.addImageSync to support the order of execution fix in LabelCollection
- ArcGisMapServerImageryProvider.readyPromise will not reject if there is a failure unless the request cannot be retried.
- SingleTileImageryProvider.readyPromise will not reject if there is a failure unless the request cannot be retried.
The majority of the changes lie in the Specs, where unresolved promises weren’t being awaited before finishing executions, and where resolved promises are assumed to be synchronous all over the place and needed a good amount of fixes. Another issue which came up was calling Promise.reject in the body of a spec can cause node to halt execution when running via the command line.
Locked to version 6.7.0 since that is the version we are already using and
updating it requires additinal work because of the use of util.lazyResolve
in the GoogleEarthEnterpriceMetadata root parser code.
Rather than submit libraries to Source/ThirdParty, which always end up
being modified for our build system and quickly go out of date, this
change starts to use libraries via npm instead. Currently Autolinker,
earcut, when, tween.js, rbush, kdbush, quickselect, and topojson are
ported.
The main hurdle that prevented us from doing this sooner was the fact that
Cesium has a long history of not requiring a build step after every code
change and has a goal of writing valid JS code, unlike many libraries today
that mandate a bundler to turn invalid JS code into valid code.
Rather than mandate a bundler during development, this initial step adds a
"buildThirdyParty" function to the current "build" step. This function runs
third party libraries (defined in the ThirdParty/npm/ folder) through
RollUp and creates an equivalent file in `Source/ThirdPartyNpm`.
The change to end users will be non-existent, especially since the combined
Cesium.js will still re-export any third party modules as part of the
private API just like it used to.
This doesn't prevent code duplication for users using some of the same
third party libraries as Cesium. This is just an improvement as to how
depend on third party libraries internally.
I think Cesium's days of being "bundler free" are probably limited long
term, performance is the main hurdle and newer tools like esbuild may make
that no longer a problem. But that's outside the scope of this initial
goal.
Gabby Getz
Eli Bogomolny
ebogo1
Matthew Amato