@tschoartschi errm, where did I say uglifyjs
will just do all the magic itself?
You should take a look on that webpack
issue I’ve sent above, since I mentioned uglifyjs
just in case of this issue - https://github.com/mishoo/UglifyJS2/issues/1261
Also, I finally have found some free time and tested the whole process myself.
I am using webpack
4.0.0-alpha.1 in production mode and three
89 installed from npm
.
Importing from three.module.js
(default)
import { Color } from 'three'
Importing from three/src
(custom)
import { Color } from 'three/src/math/Color'
Results:
D:\playground\testing\3js-treeshaking>ls build -ghs
total 520K
508K -rw-r--r-- 1 None 507K Dec 21 16:32 from-module.5ee237e47d.js
12K -rw-r--r-- 1 None 8.9K Dec 21 16:32 from-source.662ff426c2.js
Conclusion:
Importing from source gives us ability to tree-shake our bundle. I haven’t tested it with rollup
, but I think everything should be fine.
Caveats:
Importing from source also requires shader files proccessing, so take care of supporting glsl
file format with additional loaders or methods.
Real world usage note:
three
is an powerful library and it’s size fairly huge compared to other things in webdev. Tree-shaking is not an silver bullet, but one of the availble methods. We’re better should focus in what condition (using minification and code-splitting) and how is our code is sent (using http2
and gzip
or br
content compression) to end-user. Stack and methods may vary, as always it depends of project.
For example, in an dead-simple application that is additionally using GLTFLoader
(and it imports a better half of the whole library) and loading single model the difference beetwen bundles after minification was 96KB and just 18KB after gzip
.