I simply don't see how this works. (Nevermind, I think I see, it's a namespace convention in light of a time before modules)

[trusktr]

In the example HTML file entry points, I don't see any reference to THREEx, and I don't see how THREEx hooks into Three.js.

Can you explain how it works, and where to look to see how it works?

[trusktr]

I think I'm getting it: THREEx is just a namespace with anything in it, then we just simply use anything in it inside of a THREE.js scene, but there's not specifically some plugin architecture or pattern to follow except that a constructor should just return something useful.

For example, three.curvehelper.js just makes a constructor that returns a Three.js object, and then in the extrude example we're just using it.

So if I understand correctly, THREEx is simply a convention for storing anything in a namespace, and that nowadays we could just use ES2015+ modules to encapsulate anything without a namespace.

What would be interesting would be to ship all the functionalities you have here as JavaScript modules (f.e. on NPMjs.com) and use that form of organization, while shipping also a global build of the module that someone can use via script tag. (people are moving away from Bower these days, towards modules).

[trusktr]

In this example, what I see is that THREEx is basically a namespace, and the script tag ordering has to be done manually. This is all basically solved with modules.

Maybe we can migrate to using ES2015 modules, then update the website to pull the modules onto the website by looking at a threex tag on NPMjs.com, and each module could be a matter of npm install whatever-it-is-called to get it into the project.

Having a global build of the tool makes it still publishable to Bower's registry (f.e., a dist folder can house the global version), while other users that use Webpack, Rollup, Browserify, etc, can just use the source code (or transpiled source code) directly without using the global version.