package size and inlined dependencies about three.js

[donmccurdy]

but nothing inside, for instance, examples/jsm/libs can even be used

This claim is incorrect. Static resources cannot be fetched from node_modules in most cases, but JavaScript modules certainly can. Any use of KTX2Loader is getting dependencies this way:

three.js/examples/jsm/loaders/KTX2Loader.js

Lines 61 to 62 in ed2bfb2

	} from '../libs/ktx-parse.module.js';
	import { ZSTDDecoder } from '../libs/zstddec.module.js';

If I create a new react+next.js-based project with three.js, my dependencies could easily look something like this:

That's obviously not great, but three.js is not a particularly bad offender on the list either. Is this such a major issue that we'd need to throw all of examples/jsm/libs out?

I understand the R3F community is using three-stdlib rather than these files, and perhaps a more complete proposal could be made to change how we're structuring the project, but I don't feel this issue currently describes motivating reasons for such a change.

[marcofugaro]

I believe we can do something similar to the webgl_geometry_csg example, for the examples on the website we can use import maps pointing to unpkg.com, whereas on npm we could declare the packages as optional peerDependencies.

However this comes with the burden of having to tell the user to install a specific version of fflate when using the FBXLoader for example. What's your view on this?

[mrdoob]

Does anyone want to do a treemap to illustrate what contributes to these 23mb?

[LeviPesin]

However this comes with the burden of having to tell the user to install a specific version of fflate when using the FBXLoader for example. What's your view on this?

I think that users already do something like this for packages like react-three-fiber, so it shouldn't be too much of an issue?

[drcmda]

the javascript files can, but what's the point when each and every one of them is on npm, a package should avoid inlining dependencies. but the binaries cannot be used in a meaningful way, they are there for nothing.

as for stdlib, three + jsm/examples is being present always, and in larger projects it contributes to install times and slow tooling.

std declares all dependencies properly
https://github.com/pmndrs/three-stdlib/blob/main/package.json#L36-L48 but it can't help the weight that is caused by three.

[Mugen87]

Is this such a major issue that we'd need to throw all of examples/jsm/libs out?

Definitely no.

perhaps a more complete proposal could be made to change how we're structuring the project, but I don't feel this issue currently describes motivating reasons for such a change.

Agreed.