How about making examples/jsm/ all import src/Three.js instead of build/three.module.js?
This will greatly facilitate source code testing and debugging.
What would be the side-effects besides easier debugging?
May slow down the download speed of the official website examples, because it use examples/jsm/ not examples/js/.
Shall we change it to examples/js/ ?
But wouldn’t it be missing all other features that come through rollup.config.js - glconstants, polyfills, glsl (also addons, but these don’t matter much.) ?
Because - if I get it correctly - you want to change imports in all example modules (ex. GLTFLoader, OrbitControls), not official examples (webpages with three showcases), right?
Yes, change all, in fact, my main purpose is change modules like OrbitControls.
I am not familiar with webpack optimization and treeshaking, but since modern browsers have directly supported <script type="module">, I think there is no error in using hierarchical import directly, it is just not the optimal way.
That’s slowing down loading, it will have to fetch every single file and can fetch deeper ones after others are loaded. three.module.js is like a cache for all that.
Yes, so how about let official examples use examples/js/ for performance reason and let examples/jsm/ use pure js module system?
The non-module system can only work with the bundle anyway. And examples/js is about to get removed in december, loading the entire hierarchy of all files isn’t reasonable, for developing you can import the entire files locally if really needed, i wouldn’t recommend that though.
Ok, I found I also neglected that if use examples/js/, will need change all examples’ htmls back to non-module style.
Not any more 
It won’t get removed?
1 Like
I see, i understand why not having everything double files like with typescript would be prefered, but i also agree with keeping, asides of browser support not everyone uses a workflow with ES6 modules exclusively but the kind of modules that work without ES6 like requirejs or such, if they would disappear from the CDN link that would also break thousands of examples online as well.
And ES6 modules encapsulate, which could break the most if not exclusively using this system or a transpile step.
tried to point this out once, both src/three and build/three.module are conventionally wrong - the only correct import value is “three”.
a current project using “three” and, say, orbitcontrols, can end up with two distinct threejs versions since the bundler only cares about package.json:module/main and resolves “three” towards that. if any import url differs from what it would naturally resolve to, it treats it as a new namespace. at the moment this happens in all commonjs environments using examples/jsm - they all run on two threejs without exception.
Finally , I replaced all build/three.module.js with src/Three.js in the ./examples folder of my own branch, looks ok now.
Theoretically with HTTP2 this should be less of a problem - it can fetch multiple files in a single request. However, I don’t know what the limit is. I suspect it’s intended for tens of files rather than the hundreds that make up the three.js src/. Would be interesting to see benchmarks on this.
However, it’s still not a good idea since as @mjurczyk says the src files are processed to create three.module.js and you’d lose that benefit.
I was wanting to ask exactly same thing. It is not a big deal personally to make a copy of an example and change import to src/Three.js instead of build/three.module.js .
The reason is that I am building a compact build of threejs that is 420k minimized(not gzipped), so bundler then knows to import what is needed.
I am comemnting here to be on the lookout if this changes in Threejs so I can update my example.