Inline Static Assets in Builds

[ggetz]

The current CesiumJS distribution consists of a single, bundled JS entry point, Cesium.js, which inlines all library JS code. It also ships with several other static files, including standalone Worker JS files, third party wasm files, JSON data, images/textures, and CSS files. Depending on what features of the library is being used, some or all of these static files are required to be loaded at runtime.

While we've operated with these static files as part of the distribution since the beginning, it can require extra infrastructure on the part of developers depending on CesiumJS. We'd like to re-evaluate our strategy and look into providing a single-file CesiumJS distribution

As a first step, we could allow an optional inline flag as part of the build script. esbuild has a loader option which allows other file types besides JS to be inlined most likely as data urls.

After ensuring everything works, we should put some thought into potentially shipping by default as part of the release zip.

[ggetz]

Tangential to this discussion, for those that are using CesiumJS from Source, we'll also want to ensure the proper files are exported via package.json.

[ggetz]

@TJKoury You have some experience with doing this, via rollup I believe, in https://github.com/DigitalArsenal/c137.js. Are there any gotchas that you may have experienced in the process?

[TJKoury]

Plenty gotchas! I'll start with the big one (for me): WebWorkers.

My approach was to import all the webworkers into a single file. The packager can walk the dependency tree and pull everything into a single worker that can be called whenever you need a worker.

That is then injected as a string into TaskProcessor.js. Since this will now be part of the official build you can probably come up with a more elegant solution (import it using the esbuild loader option per the above).

[TJKoury]

@ggetz I’m considering applying for a grant through the new program so I can dedicate some time towards adapting my old approach to the current build system. If this will be duplicating effort, let me know.

[ggetz]

@TJKoury Awesome! Please go ahead!

[TJKoury]

@ggetz I'm assuming since it's now in the backlog that this is no longer a priority?

[ggetz]

@TJKoury this is still on our shortlist.

I moved it to backlog because no one on the Cesium side is currently scheduled to work on it. Mostly just reorganizing the labels on my side.

[TJKoury]

Ok, standing by. I did apply for the grant program.

[brunokunace]

@pjcozzi @mramato this project is dead? i am trying to make a plugin for meetings inside geospace, but the current version dont work with a simple project, need to use fork for other people to make it work... Have any developer of Cesium team for check this repository?

[ggetz]

I've done some prototypes of inlining worker in the worker-inline branch.

[TJKoury]

Just tested it out, looks good and works very well with the new build system.

[TJKoury]

@ggetz Now that you have created an approach that works with your new build system, let me know if there's anything I can do to speed things along.

[ggetz]

Thanks @TJKoury! Now that inline workers are shipping in Cesium.js, the next step would be to inline additional files, such as images, JSON, and CSS. If you have some bandwidth to look at that, let me know.

[TJKoury]

Question: do you think CSS should be bundled by default? All build tool chains are able to handle CSS imports, either natively or using a plug-in.

[TJKoury]

@ggetz What about building it in by default for the ES6 modules, so that it works in build systems like Vite? Instead of making it a global, it can be imported as a string from a Resources.js module, which can also have the images, JSON, CSS, .wasm binaries as base64, etc.

If this approach is something you would consider, let me know.

[ggetz]

@TJKoury Sorry for delay here!

I think additional CSS imports are a commonality that users will be used to and be able to find resources to handle. Just for some context, up until this point, we've tended to package the ES6 modules as minimally as possible with the ides that users we have more flexibility in their build process. And we've packaged the built Cesium.js as more of CDN with as much included as possible.

What about building it in by default for the ES6 modules, so that it works in build systems like Vite? Instead of making it a global, it can be imported as a string from a Resources.js module, which can also have the images, JSON, CSS, .wasm binaries as base64, etc.

Are you talking about the workers in particular here? We'd be open to other approaches.

[ggetz]

Brought up on the forum: https://community.cesium.com/t/porting-from-1-100-to-1-120-to-load-google-3d-tileset/34809/6