In #16220 we're considering converting the examples to use <script type=module. There should be very little overhead when importing a couple of files, as will happen when we use three.module.js.

However if we do this while importing from src/, we'll be importing potentially hundreds of files, which means hundreds of extra network requests. We'll need to consider how much that will degrade performance.

@looeee I didn't know about those plans, you're right, three.js needs to be imported as a bundle in the esmodules examples.

So how would we go about importing

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader'

without importing the whole bundle like we do with

import { Vector3 } from 'three/src/math/Vector3'?

Hmm, I can't think of any easy way around this right now. We either get easy tree-shaking (but Webpack only, I think?), or we get to convert the examples to use <script type="module".

I'm inclined to think that converting the examples is more important, and it's up to people to get tree-shaking working in their own apps. They would need to do this:

import { Vector3 } from 'three/src/math/Vector3'; // from NPM package
import { OrbitControls } from './local_dir/OrbitControls.js';

Then in the local copy of OrbitControls, they'll need to change

import {
	EventDispatcher,
	MOUSE,
	Quaternion,
	Spherical,
	Vector2,
	Vector3
} from "../../../build/three.module.js";

to import from the various three/src/... files in the NPM package. Which is going to be a bit annoying if they are using lots of examples. But we can at least make things easier by documenting this and adding "sideEffects": false in package.json.

You're right, webpack should tree-shake the three.module.js, but it doesn't and I found a bug about it. I guess let's leave it like this and wait for the tools to catch up.

I'll make a separate PR for the "sideEffects": false flag