Why have 2 build targets?

CesiumJS
1

Cesium currently has 2 build targets, minified and unminified, with CJS and ESM for each.

I was wondering why not just build once, unminified ESM? (or both ESM & CJS, depending on browser & Node.js support)

From what I know, libraries usually provide unminified code, since it’s likely they will be used in a project with a bundler that will minify if needed.

I don’t know if this is the case for Cesium, since I don’t have the statistics for how the library is used.

2

Hi @EliasVal, welcome to the community!

I think the minified build is still useful for web-based imports. For example, you may want to use Cesium to display a globe on a web-based notebook. You could then import Cesium from a CDN without needing to host the bundle yourself.

You are correct that if you are bundling Cesium into your own project, and then uploading the bundle to a server, it will work just as well to import the unminified code. The unbundled code might even be better for debugging purposes.

3

Thanks!
I see.
Two more questions I have are why not TS? and why manually install third-party libraries into the project? (jshint, codemirror, dojo)
I’m looking forward to contributing to the project at some point, and these are just some questions I have :slight_smile:

4

The first version of CesiumJS was written before TypeScript was released. There has been discussion of TypeScript since then (see CesiumJS#4434) but I’m not aware that any current maintainers are advocating for a rewrite in TypeScript… so there’s been no explicit decision for or against it. However, we are in the process of adopting type checking using JSDoc annotations in .js files. This allows you to use the TypeScript Language Service to detect type errors from your code editor and in GitHub Actions, as if you were writing .ts files. For more on this approach, see this interview with Rich Harris, the creator of Svelte, who does the same.

I don’t know the history of why those dependencies were vendored, but I think that (moving forward) the general preference is to avoid new dependencies when possible, or to install them through npm / package.json / node_modules otherwise.