Feature Request: Break out loaders into independent module

Is your feature request related to a problem? Please describe. No, it is not. This is more of a distribution thing in relation to code.

A clear and concise description of what the problem is. Ex. I’m always frustrated when […] Why aren’t the loaders isolated into their own module, and why do all references to say - the GLTFLoader, recommend you just directly reference the code? This seems to be the case for all loaders that are maintained by the threejs team, and it seems like an odd choice from an outsiders perspective. The loaders are coupled within threejs and are therefore tied to the release cadence of threejs itself. And, hosting the loader code within the examples folder may give the wrong impression for other users of threejs that this code is actually a library to use with threejs.

It seems counter productive to have the loaders by tucked away inside of the examples folder when a lot of the documentation makes use of any threejs loader that is maintained by the threejs team.

Describe the solution you’d like A new ES Module that contains all of the officially supported(as in threejs team currently actively maintains) loader classes for threejs.

A clear and concise description of what you want to happen. All of the threejs loaders that are considered to be first-class support status by the threejs team to be isolated into its own ES Module, with a separate release cadence from threejs proper.

Describe alternatives you’ve considered Possibly moving the loader files out of the examples folder, so that its not potentially giving the wrong impression to new developers to not use these loaders, maybe? An import-map can also satisfy the requirement of an ES Module.

A clear and concise description of any alternative solutions or features you’ve considered. N/A; see above.

Additional context I am arguing from the perspective of a user of threejs that it seems unnecessary to require an entire release of threejs for fixes that are specific to the loaders themselves, which is why I argue in favor of a separate release cadence from threejs proper. This wouldn’t mean that the two would be completely decoupled; rather, it would just free up the accessibility to new loaders, bug fixes, etc, that are specific to threejs loaders from the rest of the codebase.

Add any other context or screenshots about the feature request here. N/A

[gm112]

Hmm, fair point. You would have to maintain a separate thread of issues, as well as release cycle in addition to threejs, hence the bandwidth problem being a long-term issue. Well, I appreciate you answering and providing additional feedback!

[mrdoob]

Thanks for the tl;dr.

Unfortunately the consequences of such change is something we currently do not have the bandwidth for.