Testing AMD modules with buster.js and require.js

570 views
Skip to first unread message

Rene Møller

unread,
Jun 3, 2012, 5:39:07 PM6/3/12
to bust...@googlegroups.com
Hi

I am trying to test a project that used AMD modules via the require.js 2.0.1 loader.

I have put a small isolated example up on github.
https://github.com/rhmoller/buster-amd-example

The "production" code is in script/example and the test code is in script/test
main includes greeter

But buster complains with

Firefox 12.0, Linux  ./require-jquery.js:175 Uncaught Exception: Script error                        
                     http://requirejs.org/docs/errors.html#scripterror         Firefox 12.0, Linux  Unable to load script ./greeter.jsundefined Uncaught Exception:                                                                          Firefox 12.0, Linux  ./require-jquery.js:175 Uncaught Exception: Script error                        
                     http://requirejs.org/docs/errors.html#scripterror  

If I change the greeter-test.js to require "example/greeter" and change greeter.js to define "example/greeter" instead of just "greeter" it works in buster - but no longer in the browser.

Best regards
Rene

Tiago Rodrigues

unread,
Jun 3, 2012, 7:06:30 PM6/3/12
to bust...@googlegroups.com
Hi there!

Well, you practically answered your question on that problem description! But yes, it's not obvious at first, and unfortunately the combination of buster and AMD is not so good at highlighting these problems clearly. I know I've lost my fair share of time debugging similar issues and every once in a while I still get a bit confused.

Put simply, you need to load a configuration for your loader, in your case require.js (I use curl.js). Take a look at this: http://requirejs.org/docs/api.html#config

What you need to have on that file is basically a paths config that maps greeter to example/greeter, something like this:
{
  "paths": {
    "greeter": "example/greeter"
  }
}

This usually gets AMD newcomers by surprise, so make sure you read more about paths configs on AMD to understand better why this needs to be done.

You should specify it in a separate file and load it in the libs section, along with your loader library. You can probably even have different config files for testing and actual use on your application and build processes.

I personally like to keep just one file, so I use some additional tricks to sort of automatically prepare one file for testing based on the original file, but saves the trouble of having to specify those configs in more than one place.

Also, something which I have found out in the past couple of days is loading the modules to test in a bit of a different way (slightly more verbose) which I think helps me figure out better which modules have problems when you start to have big trees of dependencies. I've forked your example to demonstrate:


This is just something I think it's better and it's by no means a proven way of doing things better, and when you do have syntax errors on modules which are dependencies of what you are testing, you usually see similar script/syntax errors on loading files that you have no idea where they come from.

Let me know if any of that helps!
--
Tiago Rodrigues
http://www.trodrigues.net
E-Mail / MSN Messenger / Jabber / GTalk:
  tmcrodrigues [at] gmail [dot] com
Skype: trodrigues.net

Rene Møller

unread,
Jun 4, 2012, 1:42:20 PM6/4/12
to bust...@googlegroups.com
Hi,

Thank you very much.

I have applied your suggestion and it works. When I run the buster test suite I have a different baseUrl, so the "paths" mapping allows me to redirect the includes to the correct locations.

I have updated the git repository with the working version, and I also added an example of remapping a module path. I was relieved to find that I did not have to remap each individual production file.

/Rene


On Monday, June 4, 2012 1:06:30 AM UTC+2, Tiago Rodrigues wrote:
Hi there!

Well, you practically answered your question on that problem description! But yes, it's not obvious at first, and unfortunately the combination of buster and AMD is not so good at highlighting these problems clearly. I know I've lost my fair share of time debugging similar issues and every once in a while I still get a bit confused.

Put simply, you need to load a configuration for your loader, in your case require.js (I use curl.js). Take a look at this: http://requirejs.org/docs/api.html#config

What you need to have on that file is basically a paths config that maps greeter to example/greeter, something like this:
{
  "paths": {
    "greeter": "example/greeter"
  }
}

This usually gets AMD newcomers by surprise, so make sure you read more about paths configs on AMD to understand better why this needs to be done.

You should specify it in a separate file and load it in the libs section, along with your loader library. You can probably even have different config files for testing and actual use on your application and build processes.

I personally like to keep just one file, so I use some additional tricks to sort of automatically prepare one file for testing based on the original file, but saves the trouble of having to specify those configs in more than one place.

Also, something which I have found out in the past couple of days is loading the modules to test in a bit of a different way (slightly more verbose) which I think helps me figure out better which modules have problems when you start to have big trees of dependencies. I've forked your example to demonstrate:


This is just something I think it's better and it's by no means a proven way of doing things better, and when you do have syntax errors on modules which are dependencies of what you are testing, you usually see similar script/syntax errors on loading files that you have no idea where they come from.

Let me know if any of that helps!

Stein Magnus Jodal

unread,
Aug 15, 2012, 9:42:24 AM8/15/12
to bust...@googlegroups.com
On Sun, Jun 3, 2012 at 11:39 PM, Rene Møller <rhmo...@gmail.com> wrote:
> Hi
>
> I am trying to test a project that used AMD modules via the require.js 2.0.1
> loader.
>
> I have put a small isolated example up on github.
> https://github.com/rhmoller/buster-amd-example

Hi,

Every time somebody ask about how to make Buster.JS and AMD/Require.JS
play together on #buster.js, this thread is referred to for reference.
Thus, I thought I'd put a note here about a Buster.JS+AMD example
project I've made, which also makes use of the require-cs loader
plugin to compile CoffeeScript. I believe the example is useful even
if you're not using CoffeeScript, as it has lots of comments trying to
explain what each moving part is for.

You can find the code at
https://github.com/jodal/buster-coffee/tree/master/demo-amd

--
Stein Magnus Jodal

Tiago Rodrigues

unread,
Aug 16, 2012, 4:14:16 AM8/16/12
to bust...@googlegroups.com
Great stuff! I'll try to take a better look at it later and see if I can add anything useful.

Christian Johansen

unread,
Aug 16, 2012, 4:22:39 AM8/16/12
to bust...@googlegroups.com
If any of you who have actually worked with Buster/AMD would like to turn this thread into busterjs.org/docs/amd or similar, I'd cheer loudly.

Christian
--
MVH
Christian
Reply all
Reply to author
Forward
0 new messages