📦 Bundle size

Full ESM build, minified and gzipped.

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

@Mugen87 Do you see any issues with this change?

Basically no but I always wondering if updating the code base to fix such issues is the right step.

To me, the minify tool would be the better place for a fix.

I'm OK with the changes, no objection! These requirements have been in Closure Compiler for a long time, if I remember correctly. I am worried that it will be difficult to avoid regressions in future versions though, since we don't use these compilers ourselves and ESLint can't detect the problem, so it's hard to make guarantees about future compatibility.

To me, the minify tool would be the better place for a fix.

This is possible by using lists of property names to not change (Closure Compiler calls these "externs"). There are two downsides with this though: firstly those names are globally prevented from renaming, so for example if the name material is on the list, it will never rename it even in cases where it is safe do to so. If you end up with huge lists of properties to not rename - which looks likely with a large library like this - then it can significantly impact the effectiveness of property mangling. Using string property syntax allows marking specific cases to not rename, e.g. obj["material"] will not be renamed, but obj.material is allowed to be renamed. A second downside is that in my view maintenance is more difficult: if someone does something like add a new property to ShaderLib, then property mangling is broken until the name is added to the externs list; if it's using string syntax instead, and the author just copies the existing string syntax to be consistent with all the other properties, then it still works. In other words there's a single place to specify properties not to be renamed, which is in the codebase itself. (Experience dealing with similar situations in Construct led me to end up using string syntax over long lists of externs.)

I am worried that it will be difficult to avoid regressions in future versions though

If nobody cares about property mangling other than us, I'm happy to maintain it and submit fixes if we notice it break. Most likely we will do incremental updates on this to cover just the parts of the codebase we need and maintain them if anything stops working with property mangling. And if things stop working with property mangling, all it means is something used dot syntax instead of string syntax, and that doesn't affect anyone else, so the impact of any regressions should be strictly limited to property mangling.

Hmm...

Do you know what kind of saving are we talking about here? How many kb? And what % of that is relative to the whole game package?

Using UglifyJS:

uglifyjs three.module.js --compress --output thee.module.simple.min.js
uglifyjs three.module.js --compress --mangle-props keep_quoted --output thee.module.advanced.min.js

So advanced brings the script size down a further 33% (and 17% zipped) relative to simple minify.

Closure Compiler does better, but it has dead code elimination in advanced mode and the file size is so much smaller I suspect it just deleted a lot of code as it was just fed a library script on its own (which I suppose is therefore entirely dead code). So the above figures should be seen as a baseline that Closure Compiler would probably beat.

FWIW advanced mode also provides stronger protection against reverse engineering which is important for Construct developers.