Return to Answer

I know of no good reasons not to do it if the organization helps. I consider your classes and static getters to be an internal implementation detail that can expose a pattern that's already used heavily in popular JS libraries. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}

Consider this fictional version of mongoose in es6 that uses classes:

export default class Mongoose {
    constructor() {
    }

    static get model() { return require('./model.js'); }
}

And that can be used just like the real mongoose with:

var mongoose = require('mongoose');

new mongoose.model(...);

I know of no good reasons not to do it if the organization helps. I consider your classes and static getters to be an internal implementation detail that can expose a pattern that's already used heavily in popular JS libraries. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}

Consider this fictional version of mongoose in es6 that uses classes:

// mongoose/index.js
export default class Mongoose {
    constructor() {
    }

    static get model() { return require('./model.js'); }
}

//mongoose/model.js
export default class Model {
}

And that can be used just like the real mongoose with:

var mongoose = require('mongoose');

new mongoose.model(...);

I know of no good reasons not to do it if the organization helps. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}

I know of no good reasons not to do it if the organization helps. I consider your classes and static getters to be an internal implementation detail that can expose a pattern that's already used heavily in popular JS libraries. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}

Consider this fictional version of mongoose in es6 that uses classes:

export default class Mongoose {
    constructor() {
    }

    static get model() { return require('./model.js'); }
}

And that can be used just like the real mongoose with:

var mongoose = require('mongoose');

new mongoose.model(...);

I know of no good reasons not to do it if the organization helps. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}

I know of no good reasons not to do it if the organization helps. Many libraries already expose a single object hash with types, so this isn't much different.

I see no difference between that and, say:

// foo.js
module.exports = {
   OtherFoo: require('./otherFoo.js')
   OtherFoo2: require('./otherFoo2.js')
}