7 thoughts on “Moving to a modular architecture

  1. Some other advantages:

    • You can structure your code
    • You can create / reuse modules without polluting the global namespace
    • You can build for production
    • You can debug more easily since every module has it’s own file you don’t need to search for the corresponding module in a large three.js file
  2. @mrdoob

    import/export is just the way modules are declared and required. It will not affect/change the code defined within the modules at all:


    // Mesh class, stays the same as today (except the export part)
    var Mesh = function ( geometry, material ) {
        // ...
    export default Mesh


    // Library entry point, exports all files using som bundling tech
    // In a "THREE" namespace for browsers
    // As import three from 'three' in node
    import Mesh from './objects/Mesh'
    export {Mesh} // All three objects, such as Geometry, Material etc..


    // In node
    import {Mesh} from 'three'
    var mesh = new Mesh(geo, mat)
    console.log(mesh instanceof Mesh) // true


    // In a browser
    var mesh = new THREE.Mesh(geo, mat)
    console.log(mesh instanceof THREE.Mesh) // true
  3. Right, so it will require a bit of refactoring…

    I got you! Since this thread got lively over the last couple of days I’ve been working a bit more on three-jsnext. It’s a project that takes the existing Three.js codebase and turns it into ES modules automatically. Just wrangling with a couple of tricky cyclical dependencies (particularly around KeyframeTrack), but should have something to share real soon. As far as I can tell, all the examples continue to work, and the minified build is smaller than the current one (using Rollup to generate a UMD file), so it’s all good news.

Comments are closed.