Access RequireJS path configuration

Question

I notice in the documentation there is a way to pass custom configuration into a module:

requirejs.config({
    baseUrl: './js',
    paths: {
        jquery: 'libs/jquery-1.9.1',
        jqueryui: 'libs/jquery-ui-1.9.2'
    },
    config: {
        'baz': {
            color: 'blue'
        }
    }
});

Which you can then access from the module:

define(['module'], function (module) {        
    var color = module.config().color; // 'blue'
});

But is there also a way to access the top-level paths configuration, something like this?

define(['module', 'require'], function (module, require) {        
    console.log( module.paths() ); // no method paths()
    console.log( require.paths() ); // no method paths()
});

FYI, this is not for a production site. I'm trying to wire together some odd debug/config code inside a QUnit test page. I want to enumerate which module names have a custom path defined. This question touched on the issue but only lets me query known modules, not enumerate them.

Honaker

Answer 1

I don't believe require exposes that anywhere, at least I can't find it looking through the immense codebase. There are two ways you could achieve this though. The first and most obvious is to define the config as a global variable. The second, and closer to what you want, is to create a require plugin that overrides the load function to attach the config to the module:

define({
    load: function (name, req, onload, config) {
        req([name], function (value) {
            value.requireConfig = config;
            onload(value);
        });
    }
});

Shading

Answer 2

It is available, but it's an implementation detail that shouldn't be depended on in production code ( which you've already said it's not for, but fair warning to others! )

The config for the main context is available at require.s.contexts._.config. Other configurations will also hang off of that contexts property with whatever name you associated with it.

Trampoline

Good answer, but quick question. Why not use this on production code? – Notarial

@Notarial Because things might change with this object in future(since its not exposed directly or available in doc) and you dont want to break your production code abruptly. – Celadon