Cesium ES6 Module Support

While there was some discussion in #2524 related to ES6 module support, we never actually wrote up an issue to track it specifically. Below is my current best guess for a list of tasks we’ll need to implement and questions to sort out. This is a living document, so I expect to update this description as we learn more.

Assumptions

• The goal of this issue is to switch to ES6 modules, not allow for other ES6 features, such as async/await, that would require transpiling with Babel. We will tackle that as a separate enhancement once initial ES6 work is done.
• We do not want to add any additional build processes for development, Chrome/Firefox/Edge/Safari should “just work” with the minimal build we have in place
• We want to retain the ability to test against the combined build if possible.
• IE11 and Node.js will require a build step to run, since IE 11 does not support ES6 modules and Node support is still experimental.
• For users who currently use the combined Cesium.js file, nothing should change.
• With ES6, there’s no longer a reason to use Cesium modules directly. The official Cesium build will change to 4 options:
  • The traditional combined/minified Cesium.js
  • The traditional combined/debug Cesium.js
  • ES6 combined/minified Cesium.js
  • ES6 combined/debug Cesium.js

Prep work

• Replace coverage with karma-coverage; #8115
• De-customize our jasmine so we can support ES6 unit tests: #8120
• Update gltf-pipeline build for Cesium to output ES6 (can technically happen after)

Actual migration

• Write script to convert individual modules to ES6. (Starting in es6-playground branch)
• build task should output shaders and Cesium.js as ES6.
• Refactor Workers to be based on ES6 instead of requirejs
• Switch to roll-up based build system. (A lot of “sub-tasks” probably involved here as well)
  • Plugin to deal with pragma
• Update CesiumViewer to a ES6/roll-up app.
• Delete or update TimelineDemo
• Update release zip generation to only include what’s required.
• Get unit tests running
• Update Sandcastle (Stays ES5 but bucket uses ES6 Cesium?)
• Update actual Sandcastle html demos and rename bucket
• Figure out new zip packaging for ES6
• Move Workers to WorkersES6 and Workers/Build to Workers
• Test against the built version of Cesium

Open Questions

1. Do we try and continue to provide AMD modules (at least temporarily) or do we make a clean break for ES6. This only affects people using our AMD modules without a system that supports ES6 (which is almost no one) so a clean break is my vote.
2. Since Specs will be ES6 too, it may be impossible to unit test in IE11 without a completely different approach. This is probably okay since IE11 is not longer for this world.
3. What are we forgetting?

[markerikson]

FWIW, I did a mass AMD->ESM codemod migration on a work app last fall. I documented my workflow here:

https://blog.isquaredsoftware.com/2018/11/git-js-history-rewriting/

The specific details on codemods are here:

https://blog.isquaredsoftware.com/2018/11/git-js-history-rewriting/#rewriting-js-source-with-codemods

And I put up a repo with the conversion scripts I wrote:

https://github.com/markerikson/git-js-repo-history-conversion-utils

In my case it was even more complicated because I was trying to rewrite the entire app history to look like the code had always been written in ES6 syntax.

[mramato]

I’m not sure the npm tarball will shrink much, if at all.

~Actually, this is a separate bug. We appear to be shipping the Apps folder as part of the build and that shouldn’t be the case. Pretty sure we’ll cut off 9 megs just from that.~

I was wrong, master is correct and clocks in at 25MB. However the ES6 port should shrink this by 9MB because our workers now share code.