Dependency update strategy

[javagl]

Some of the rendering engines are a bit outdated...

[====================] 24/24 100%

 @types/mocha                        ^9.0.0  →   ^10.0.1
 @types/node                       ^14.0.23  →   ^20.1.3
 @types/vscode                      ^1.47.0  →   ^1.78.0
 @typescript-eslint/eslint-plugin    ^3.6.1  →   ^5.59.5
 @typescript-eslint/parser           ^3.6.1  →   ^5.59.5
 ajv                                 ^8.6.3  →   ^8.12.0
 babylonjs                            5.6.1  →     6.3.1
 babylonjs-inspector                  5.6.1  →     6.3.1
 babylonjs-loaders                    5.6.1  →     6.3.1
 cesium                             ^1.93.0  →  ^1.105.1
 draco3dgltf                          1.5.2  →     1.5.6
 eslint                              ^7.5.0  →   ^8.40.0
 eslint-plugin-html                  ^6.0.2  →    ^7.1.0
 filament                           ^1.22.0  →   ^1.35.0
 gltf-import-export                  1.0.19  →    1.0.22
 mocha                               ^9.1.3  →   ^10.2.0
 three                             ^0.140.2  →  ^0.152.2
 typescript                          ^4.4.4  →    ^5.0.4
 vscode-languageclient               ^5.2.1  →    ^8.1.0
 yargs                              ^17.2.1  →   ^17.7.2

I know that it can be a pain in the back to update dependencies, for many reasons (particularly when there is a major version update, and maybe even more so when there is a minor update that should - in terms of semantic versioning - actually be a major one...).

But I wondered about the strategy for these updates, or how regularly they should be updated as part of a release.

[emackey]

Hi @javagl. Generally, any time I publish a new version, I try to get the rendering engines and certain other packages updated. A new version of this extension (2.4.0) was published just now with updated copies of BabylonJS, CesiumJS, Filament, and ThreeJS, as well as a new Draco decoder and belated updates to gltf-import-export and the glTF Validator, and of course the new JSON schema for KHR_materials_anisotropy.

A few of these dependencies are not updated. In particular, vscode-languageclient has had major breaking changes, so has been stuck on major version 5 for some years now. "Contributions welcome" as someone we both know likes to say.

During the engine update, Babylon fared well this time, but others did not. Cesium had major breaking changes to several critical API points, and required quite a bit of research (and I'm still not sure I got the "boundingSphere is ready" concept down yet). Filament and Draco both had minor API changes that needed research. ThreeJS again changed their module dependencies and required tooling updates to continue working.

Every update cycle, I must also look for size increases across all of these engines and libraries. The whole install for this extension is pushing 40 megs, which sounds small but is much larger than what VSCode would like to see in an extension. Each release, multiple new space-hogging files and folders are introduced by many of the engines, hidden in node_modules. I actually run a folder-size comparison tool and carefully look for new offenders appearing release-to-release. I surgically weed out the offenders by pattern-matching them in my .vscodeignore file so they will be left out of the published package. But doing so means that the debug build has access to a much larger node_modules than the release build, so true dependencies can go missing. So I run vsce package to build a preview of the release, and manually install that on my own machine to see if various features still work or not. This time around, Draco had a change to its dependencies, and I had to tweak its ignore list to allow it to run in release. Several other large new folders appeared uninvited in node_modules and were manually weeded out in #252. This process is probably the most hair-pulling part of publishing any new release of this extension.

But for tonight, I believe I've got the APIs working and the dependencies settled. So for now, please enjoy release 2.4.0 🚀 and let me know if you find things that break.

[javagl]

Updating the .vscodeignore indeed sounds like a pretty laborious process. Weeding out things like splashScreen.png or sampleData may be straightforward, but I cannot imagine how to come up with node_modules/cesium/Build/Cesium/Workers/*eometry* and still be sure that this will not break under certain conditions.

I think that this issue can be closed now, because 1. the dependencies are updated and 2. the question of how how/when they are updated is answered.

I'll try out the new version ASAP, and ... hopefully not (have to) report any issues.