Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

A guest post by Ben Hockey, a Senior Software Developer at Sitepen, living in Nashville, TN with his wife and 3 kids. At SitePen, he builds Web-based Applications using The Dojo Toolkit.

“If There’s a Place You Got to Get”

When developing web applications, having utility libraries to provide APIs to fill gaps and normalize differences between browsers can help ensure you Don’t Repeat Yourself (DRY). Let’s suppose that since this is such a useful thing, a third-party AMD library exists for this purpose – let’s say this fictitious library has a catchy name like belt, as in “utility belt.”

After noticing how popular belt has become, solely due to it’s catchy name, some fervent developers question the quality of the code and they realize they can match the belt API and improve some qualities of the implementation. They develop an API-compatible library, and, to reinforce that their library is a drop-in replacement, they name their library strap – a synonym for belt. Once again, competition proves to be good for the consumer and being the conscientious developer you are, you’ve made some persuasive arguments and your team is committed to using strap.

Furthering your DRY goals, you also use a number of other third-party libraries that provide some high-level abstractions that help you build your application faster, better, and stronger. Unfortunately, the developers of some of these third-party libraries aren’t fully enlightened; they use AMD but they’ve written their code to depend upon belt. Oh no! You immediately clone their repo and send them a Pull Request with an illuminating comment about why they should switch to strap.

Unfortunately, the developer of this library has some self-esteem issues that are apparently alleviated by 1000’s of people starring their repo. To that end, they believe that using belt is going to boost their chances, so they close your Pull Request with a comment like “try harder” that just leaves you confused.

Anyhow, now you’re faced with a dilemma: you’ve chosen strap for all its great qualities, but one of your external dependencies wants to infect your application with belt. You care about things like performance and code size, which is why you chose strap, but it’s all coming undone now that you’re going to have to include two libraries with the exact same API.

“I Can Get You There I Bet”

The Map Config provides a way for you to configure RequireJS so that for groups of modules, any dependencies that are requested with IDs that start with a certain prefix will have that prefix mapped to another value. “Wait, what?! That’s a lot of words”, I hear you say. Let’s see if I can make it any clearer with some code:

This configuration means that any time a module with an ID starting with 'pants' (e.g. 'pants/pocket', 'pants/zipper', etc.) makes a request for a module with an ID starting with 'belt' (e.g. 'belt/loops'), RequireJS is going to substitute 'belt' for 'strap' in the requested module ID. Now you only need to include strap and you’re DRY again!

“I’m the Map, I’m the Map, I’m the Map!”

This example shows that external dependencies for third-party libraries are in reality just abstract dependencies – pants depends upon something it named belt, but we can fulfill that dependency with any library that provides the API pants expects from belt. The ability to remap dependency IDs for collections of modules, however, is useful for more than just fulfilling abstract dependencies. You can use map for:

    • Multiple version support when libraries require different versions of some other library.

    • Resolving ID clashes when libraries use the same module IDs to refer to different dependencies.

    • Working around bugs in 3rd party modules.

NOTE: This last example leverages a feature referred to as a “star map,” which is defined to work like so:

There is a “*” map value, which means “for all modules loaded, use this map config.” If there is a more specific map config, that one will take precedence over the star config.


As you can see, the Map Config is quite powerful, especially when consuming third-party libraries that have external dependencies. What other use cases can you think of for the Map Config?

Be sure to look at the RequireJS resources that you can find in Safari Books Online.

Not a subscriber? Sign up for a free trial.

Safari Books Online has the content you need

Instant Dependency Management with RequireJS How-to has a good chapter on using RequireJS and creating AMD modules.
The Twitter Flight Edge has a section on module loading with RequireJS.
Backbone.js Cookbook has a section on organizing a project structure with RequireJS.

About the author

benhockey Born and raised in Australia, Ben Hockey lives in Nashville, TN with his wife and 3 kids. As a Senior Software Developer on an amazing team of developers at SitePen, he builds Web-based Applications using The Dojo Toolkit.

Tags: DRY, Javascript, Map Config, module, repo, RequireJS, star map,

Comments are closed.