@cesium/engine and @cesium/widgets dependency definitions cause older versions to break when new versions are deployed to npm due to use of ^

[DrEchoDoobarius]

What happened?

Because of the way the dependencies for @cesium/engine and @cesium/widgets are defined with a ^, older versions get out of sync and break.
For example cesium 1.113.0 specifies the following dependencies:
"dependencies": {
"@cesium/engine": "^6.2.0",
"@cesium/widgets": "^4.4.0"
},
With the release of version 1.114.0 and corresponding engine 7.0.0 and widgets 4.5.0 version 1.113.0 will now resolve
"@cesium/engine": "^6.2.0", -> 6.2.0
"@cesium/widgets": "^4.4.0" -> 4.5
Since version 1.113.0 now will resolve widgets 4.5, the dependencies are no longer internally consistent because widgets 4.5 depends on engine 7.0.0. This will cause widgets 4.5 to pull it's own engine 7.0.0 internal dependency.
Cesium will launch fine this way but will break in subtle and non obvious ways where ever there is a type check because imported classes will come from engine 6.2.0, and widgets or it's internal engine see the 7.0.0 and different types.
Couple examples of thing's we've seen break are:

• Selection on the globe not working because a typecheck fail not recognizing the selected entity as an entity.
• Creating an entity with cesium colors eg Color.DARKGREY, and getting a developer error because a type check fails on the Color.DARKGREY.

Similar issues have occurred with previous versions since the widgets/engine split, like 1.112.0 when 1.113.0 was published. Depending on the actual versions involved it may not break, but there could be a situation where you could end up getting an entirely new unexpected version if engine and widgets both have only minor version number changes.

Reproduction steps

1. Install fresh cesium 1.113.0
2. cesium/widgets 4.5 will be resolved and it will have an internal engine 7.0.0 dependency
3. Create an entity and add it to the globe
4. Selection will not work.

Sandcastle example

No response

Environment

CesiumJS Version: 1.113.0

[ggetz]

CC #11336

Looks like the right thing to do would be to use caret versioning in the workspaces, but exact version in the top-level package. Alternatively, we could bump a major version of a package when it's dependencies go up a major version.

[DrEchoDoobarius]

I think the first option is best to give users of the library the most control over exactly what they're getting.

[mschiavone-mx]

I agree with @DrEchoDoobarius thoughts above. I found this issue and reported it here:
https://community.cesium.com/t/cesium-js-1-110-suddenly-not-working-internal-dependency-issues/27868
Sadly, it received no response, but hopefully posting here will get more support.

The temporary resolution was to add an overrides section in package.json to force the versions of the questionable dependencies. (Note that the versions below must be appropriate for the Cesium version - these can be found in the cesium package in node_modules.

"overrides": {
"cesium": {
"@cesium/engine": "6.1.1",
"@cesium/widgets": "4.3.1"
}
}

It works, but needs to be updated everytime we update the Cesium version.

[ggetz]

Also reported in #12035.