Why does the src/Three file need to be imported? My understanding of tree-shaking from the rollup documentation that it doesn't require anything to be in separate files. Is that not the case?

And I'm not sure if I agree that we should encourage importing the source file directly. I'm also not sure how this will work with plugins that try to import the existing three.js examples such as the @wildpeaks/three-webpack-plugin or when importing the new jsm ones. Have you given that a try?

Yes, if enabled with the sideEffects flag, tree-shaking would work even with the single file build/three.module.js. However the problem with that file is that tree-shaking doesn't work on stuff that is being modified in place, such as

function Vector3 () {
  // ...
}

Objec.assign(Vector3.prototype, {
  set: function() {}
  // ...
})

which is the structure of the entire codebase of three.js.
So until we don't rewrite everything with classes, tree-shaking for the main bundle won't work.
Instead it works fine with the file src/Three.js because it has only import/exports in it.

It's not encouraged but many people area already doing it. It's for people who know what they're doing.

Regarding the jsm, they would be a problem, since they import from the three.module.js. If you import from the src/ and build/, the code would be duplicated.

It's for people who know what they're doing.

Sounds like this would potentially bring confusion to a lot of users then?

TBH I think the right approach here is to change the library so that it works with tree-shaking. We should only recommend that people import from build/, not from src/.

@marcofugaro is it correct that if we change this style:

function Vector3 ( x, y, z ) {
  ...
}

Objec.assign(Vector3.prototype, {
  set: function() {}
  ...
})

to

class Vector3 {
   constructor( x, y, z ) { ... }

   set( x, y, z ) { ... }
   ...
}

then tree-shaking will work?

Class support is higher than script type="module", but again we lose IE11 support. However, people can run their code through Babel to get that support in their apps if they need it.

@mrdoob hmmm, alright.

@looeee yup, classes + sideEffects flag would work, I have tested it.

Closing this for now.

@marcofugaro there's already discussion of adopting ES6 classes in #11552, so if you want to continue this conversation please do so there.

We're proceeding step by step with adopting ES6 features, and the current focus is on converting examples/js to modules in examples/jsm. Next in line after that is adopting script type="module" in the examples (these can probably be done concurrently).

Once these are done, we can move on to the next step. IMO making tree-shaking work should be given the highest priority.

Still webpack checks if there is sideEffects: false.

Then you can still import * as three from "three" and it will tree shake from build/three.module.js

Decided to give it a go: #21313