Use with Webpack Tree Shaking?

[felixturner]

I notice if I use 'three-full' and only import the classes I need, the bundle turns out larger than when I use the regular 'three' package. (1.6 Mb vs 557Kb)

This is doing a webpack production build. Is this expected? Is it possible to get webpack tree shaking to only bundle the used parts of threejs?

BTW - thanks for making three-full. It's great for ES6 projects.

[Itee]

Thanks and thanks for feedback !

This is not expected, the tree shaking should work !

Could you provide a little example to run test against ? Because i don't use webpack in project using three-full and a little template could help a lot for this purpose.

I will give a try in my own too.

[felixturner]

sure. do you want me to email it or add it to a branch?

[Itee]

I was thinking more a setup using things like https://codepen.io/pen ? This is easily shareable and forkable.

[felixturner]

I put up a test repo here illustrating the issue: https://github.com/felixturner/three-full-webpack-test

[Itee]

Thanks a lot for the repo ! I will fork ASAP.

I made some tests and i'm asking myself about circular deps... or maybe intermediary exporter files. But there is clearly a "bug" here.

[Itee]

Just in case to help waiting a better solution...

The three shaking will work if you target the source file instead of the main es entry, like this:

//import { Vector3 } from 'three-full' // Won't shak
import { Vector3 } from '../node_modules/three-full/sources/math/Vector3.js' // Will shak

const vec3 = new Vector3( 1, 2, 3 )

console.log(vec3)

[timothyallan]

I just tried 11.3.2 to replace my three library... With Webpack 3, my production build time increased by about 5x and my bundle size increased from 3.2MB to 4.3MB. Something is def. up.
Great library though, thanks for your efforts!

[Itee]

@timothyallan Thanks for feedback.

The increase time seems to be exponential with the library size ? About the bundle size this is typically the current problem here. The tree shaking doesn't work as expected.

Like i said previously currently you should use direct file import instead of using thee-full import namespace. This should speed up the both build time and bundle size.

[timothyallan]

Yep, trying that now, but am running into the issue of ShaderChunk.js trying to import all the glsl files when I import WebGLRenderer... and webpack croaking.

ERROR in ./node_modules/three-full/sources/renderers/shaders/ShaderChunk/begin_vertex.glsl
Module parse failed: Unexpected token (5:5)
You may need an appropriate loader to handle this file type.
| //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
|
| vec3 transformed = vec3( position );

Edit: Fix is to add

       {
        test: [/\.vert$/, /\.frag$/, /\.glsl$/],
        use: 'raw-loader',
      },

in webpack config.

[backspaces]

This may be a fundamental issue with three.js, which uses techniques that break Rollup and other bundlers. Here are some links:

• mrdoob/three.js#10711
• rollup/rollup#1130

Does three-full modify the three.js code other than the module system? I have asked the Rollup folks what would have to be done to fix three.js in the rollup issue above. Maybe we can get directions from them?

[backspaces]

Suggestion: change this to "update Three code to allow for bundling" or something similar. I.e. lets not target webpack, it's too huge and complex compared to Rollup.

I think Rollup is used by webpack, so targeting it would be simpler and has a current github issue, #1130, that we could collaborate with. Here is a good article on the differences between the two.