Plan to switch to ES6 syntax

Now that IE support has been dropped in 1.84, we should make a plan to update our code. This issue can be a place to brainstorm ideas for these changes.

There are some things that need to happen before we can start making changes in CesiumJS:

• Update coding guide
• Update eslint config

Other things to think about:

• The when library is not completely compatible with native promises, use of async and await might need to be delayed until we get rid of when.
• Some ES6 features might be a performance downgrade from ES5
• Can we make the switch from var to let and const now? Some of this effort already started with the last gltf-pipeline PR: https://github.com/CesiumGS/gltf-pipeline/pull/600.

[onsummer]

I’m glad to see the official intention to update the syntax of the source code.

Using let and const avoids the problem of variable promotion in JavaScript:

if (isUnderground) { // <-  Error, `isUnderground` is not defined
  // do something
}

let isUnderground = false

if use var the above code will run well:

if (isUnderground) {
  // do something
}

var isUnderground = false

const maintains the immutability of variables:

import { Cartesian3 } from 'cesium'

const coords = new Cartesian3(100, 200, 0)
coords = 0 // Uncaught TypeError: Assignment to constant variable.

If you use var to make the code run normally, there is generally no need to change it to let and const.

For the for ... of mentioned by @ptrgags , I have seen in some evaluation reports that the performance of iterative access to the object’s key and value is acceptable, but the performance of iterative access to the array may not be as good as that of for ( let i = 0; i <someLength; i++) {/* some code */ } and the Array.prototype.forEach method.

Modularization technology has been changed from requirejs to esmodule in version 1.63, which has done a good job.

I have used the vitejs packaging tool, and have used CesiumJS in the reactjs and vuejs frameworks. Adding some guidance documents combined with these front-end frameworks maybe a good idea.

The above are some of my simple views, I hope it will be useful to the official.

---

In addition, is it possible to extract the math module of CesiumJS (most of the codes is in the Source/Core directory) separately into an npm package? This is a relatively complete js math library I have seen so far.

[sanjeetsuhag]

Background

• https://github.com/CesiumGS/cesium/issues/7102
  • Close since we don’t support IE11 anymore.
• https://github.com/CesiumGS/cesium/issues/8100
  • Investigate then close

Motivation

CesiumJS currently disallows using many language features of ES6 (as seen here). As part of our efforts to modernize the CesiumJS code base and tooling, we want to revisit our usage of ESLint and take advantage of the latest features. This will be beneficial to all contributors to CesiumJS.

Proposed Changes

Move eslint-config-cesium to its own repository

• ESLint allows for creation of shareable configurations to allow for consistency between projects, and within the CesiumJS repo, we maintain the eslint-config-cesium configuration. It is used across several repositories, albeit not all of them are updated to the latest version.
• There are three configurations exported:

  graph TD;
	  eslint:recommended-->eslint-config-cesium:::cesium;
      eslint-config-cesium-->eslint-config-cesium/browser:::cesium;
      eslint-config-cesium-->eslint-config-cesium/node:::cesium;
  classDef cesium color:#6dabe4

Upgrading eslint configuration in CesiumJS

• Inside CesiumJS, there are 6 configurations:

  • .eslintrc.json
  • Apps/.eslintrc.json
  • Apps/Sandcastle/.eslintrc.json
  • Apps/TimelimeDemo/.eslintrc.json
  • Source/.eslintrc.json
  • Specs/.eslintrc.json
  • Specs/TestWorkers/.eslintrc.json

• Here’s how they depend on each other, with ES6 configurations in green and ES5 configurations in red:

  graph TD;
	  eslint-config-cesium/node.js:::ES6-->.eslintrc.json:::ES6;
	  eslint-config-prettier:::ES6-->.eslintrc.json:::ES6;
	  eslint-config-cesium/browser.js:::ES6-->Source/.eslintrc.json:::ES5;
	  eslint-config-prettier-->Source/.eslintrc.json;
	  eslint-plugin-es:::ES5-->Source/.eslintrc.json;
	  Source/.eslintrc.json:::ES5-->Apps/.eslintrc.json;
	  Apps/.eslintrc.json:::ES5-->Apps/TimelineDemo/.eslintrc.json:::ES5;
	  Apps/.eslintrc.json-->Apps/Sandcastle/.eslintrc.json:::ES5;
	  Source/.eslintrc.json-->Specs/.eslintrc.json:::ES5;
	  Specs/.eslintrc.json-->Specs/TestWorkers/.eslintrc.json:::ES5;

classDef ES6 color:#3fb950
classDef ES5 color:#da3633

• We use the following plugins:
  • eslint-config-prettier - Turns off all rules that are unnecessary or might conflict with Prettier. I don’t believe there is any change needed here.
  • eslint-config-es - We use several rules from this, but the key plugin that we need to remove is plugin:es/restrict-to-es5 that is appled in Source/.eslintrc.json

Exceptions

As of 1.93, we use disable eslint in our code for the following rules:

• no-cond-assign
• no-unused-vars
• global-require
• no-alert
• prefer-const
• new-cap
• no-empty
• no-self-assign
• no-undef
• no-math-sign
• no-math-sinh
• no-math-cosh
• no-math-cbrt
• no-math-log2
• no-lonely-if
• guard-for-in
• getter-return
• no-use-before-define
• no-implicit-globals
• no-global-assign
• no-else-return
• no-loop-func

Note: It was easy enough to find these because in most cases, we specify the rule being broken. However, in other cases, we just use eslint-disable-line. We should enforce that all rules being broken be explicitly mentioned.

Current Rules

At the moment, the primary source of ES6 restrictions come from the eslint-plugin-es plugin. Specifically, from the use of the plugin:es/restrict-to-es5 configuration. From the source code of the module, we can see that this configuration is composed of the following plugins:

• plugin:es/no-new-in-es2020
• plugin:es/no-new-in-es2019
• plugin:es/no-new-in-es2018
• plugin:es/no-new-in-es2017
• plugin:es/no-new-in-es2016
• plugin:es/no-new-in-es2015

Since each of these is composed of many rules, it may be cumbersome to create a PR for each one. Therefore, I propose that we incrementally work through each of these plugins - with a PR for removing the restrictions for each one, eventually ending up with support for ECMAScript 2020, which is what we should set our ecmaVersion to.

Additionally, going through the ESLint documentation for environments, I noticed that the jasmine environment only adds global variables for version 1.3 and 2.0. There is a more up to date plugin called eslint-plugin-jasmine. I don’t want to update for the sake of updating, but I think it may be worth investigating once the core upgrades are done.

Another step may be to use eslint-plugin-jsdoc to ensure consistency in our documentation.

Proposed Rules

I went through all the rules available in eslint-plugin-es and found some rules that I think we may want to impose:

• ES2015
  • es/no-classes
  • es/no-computed-properties
  • es/no-generators
  • es/no-property-shorthands
  • es/no-reflect
  • es/no-rest-parameters
  • es/no-unicode-codepoint-escapes
• ES2017
  • es/no-async-functions
  • es/no-atomics
  • es/no-trailing-function-commas
• ES2018
  • es/no-async-iteration
  • es/no-malformed-template-literals
  • es/no-rest-spread-properties
• ES2019
  • es/no-json-superset

Ideally, anything we exclude we exclude with good reason. I selected these on first impression and am hoping I can get more feedback on what we should allow or not.

Upgrade coding guide

• We should confirm our theories on what ES6 features will potentially impact performance and upgade the coding guide accordingly.