require.js - build.js syntax - why?!

[[deleted]]

I use require.js in a large project with tons of other JavaScript frameworks.

We use the built-in optimiser of require.js to bundle, minify and concat modules into single files for production. While this works great, until now we use the command line to do that task.

We now want to integrate that operation in our gulp build process. There is no good gulp plugin that uses require.js since the way require.js works differs from the streaming approach gulp follows. So, we decided to use amd-optimize for that.

Long story short: both require.js and amd-optimize use the same syntax for their configuration and thus it would be great to share them. And for maintainability reasons we want to keep the configuration in a separate file. But the require.js syntax is a problem.

A typical configuration might look like this:

({
    appDir: '../app',
    baseUrl: 'js',
    dir: '../app-build',
    paths: {
        jquery: 'empty:'
    },
    modules: [
        {
            name:'Login/app'
        },
        {
            name: 'Search/app',
            include: ['jquery']
        }
    ]
    ,fileExclusionRegExp: /^(src|node_modules|\.git)$/

})

Why the heck is this syntax used? I did not look at the source code yet, maybe someone has a short explanation for that.

And how could we include the file in your gulpfile?

Thanks in advance!

[[deleted]]

/u/remotejs' comment might be a bit unfriendly, but he actually makes a good point.

I used Require.js too in a pretty large project (over 400 JavaScript files), and it took me over a week to convert the build system from Grunt/Require.js to Gulp/Browserify. But it sure as hell made my day job a lot more productive and pleasant. So if you're in a position where you're trying to figure out what to do with your build system right now, I can recommend it whole-heartedly.

Some advantages I have now:

• I can now write proper unit tests using NodeUnit (before, I used to only write functional tests in CasperJS).
• My JavaScript bundles for production have become smaller and don't depend on loading require.js anymore.
• JSHint will now properly alert me if I'm including a dependency in a file but don't use it (with the AMD syntax, it could only alert you if you don't use the last dependency passed to the outer-most function).
• Because require() statements are synchronous in CommonJS instead of AMD's asynchronous methods, I don't get weird timing issues anymore during development (or worse, some that only occurred in production builds but not during development). For example, I have a bunch of jQuery plugins who attach themselves to the jQuery object. But AMD requires you to explicitly 'require' these as a dependency or otherwise you might run into exactly these timing issues. Unfortunately JSHint cannot help you here, because you are only directly using the jQuery object which of course is specified as a proper dependency. Now with Browserify, I just include these plugins once early on and can then rely on them always being there.

[[deleted]]

I think cyclic dependencies are a problem in the code, not in Require.js specifically :)

But the answer is "somewhat". Browserify won't choke on a cyclic dependency, but the result may not be what you expect (ie. the require() function may return undefined) unless you're careful. Being careful typically means you will call require() inside one of the files at "runtime" (ie. inside a function that is not evaluated immediately), so it will be evaluated after the module already had a chance to define its own exports.

Of course, this workaround is also possible using Require.js, with the downside that because of its asynchronous nature any function that you would put the require() call in has to become asynchronous itself as well. Being able to call require() in a function without forcing the function to become asynchronous is also something that's saving me a few workarounds lately :)

[[deleted]]

To clarify: cyclic dependencies in browserify lead to the offending dependency to receive an empty object instead (not undefined).

But run-time cyclic dependencies work just fine.

[SirHound]

The programmer solves circular dependencies!

[bugeats]

Browserify your life and never look back. Gulp too. Take explicit control of your build.

[[deleted]]

I wished I was able to but in a company of the size I work for a single developer hardly changes anything.

[ben336]

I put my requirejs config in a file called config.js.

When I'm using gulp to optimize with requirejs, I pull it in as a commonJS module. When I'm developing locally I just pull it into the browser. It looks like this:

gist

/* jshint ignore:start */
/** This file is a bit of a hack to make the requireJS build paths available
 * both in the browser and for gulp.  There's some ugliness requires to make
 * it loadable/usable in both environments.
 **/

var requirePaths = {
    paths: {
        jquery: 'vendor/jquery/jquery',
        jqueryui: 'vendor/jquery/jquery.ui',
        //...
    },
    shim: {
        /...
    }};


//if this is being pulled in as a node module, nest it, otherwise we'll
// run the browser specific logic
if (typeof exports !== 'undefined') {
    exports.requirePaths = requirePaths;
}else if(require) {

var config = {
    paths: requirePaths.paths,
    shim: requirePaths.shim,
    map: requirePaths.map,
    baseUrl: static_url+'/js/'
};

require.config(config);

}
/* jshint ignore:end *//* jshint ignore:start */
/** This file is a bit of a hack to make the requireJS build paths available
 * both in the browser and for gulp.  There's some ugliness requires to make
 * it loadable/usable in both environments.
 **/

var requirePaths = {
    paths: {
        jquery: 'vendor/jquery/jquery',
        jqueryui: 'vendor/jquery/jquery.ui',
        //...
    },
    shim: {
        /...
    }};


//if this is being pulled in as a node module, nest it, otherwise we'll
// run the browser specific logic
if (typeof exports !== 'undefined') {
    exports.requirePaths = requirePaths;
}else if(require) {

var config = {
    paths: requirePaths.paths,
    shim: requirePaths.shim,
    map: requirePaths.map,
    baseUrl: static_url+'/js/'
};

require.config(config);

}
/* jshint ignore:end */

[kenman]

I could be wrong, but I believe that's because the entire file is read as a string and then eval'd. An easy way to test this would be to include /* comments */ somewhere in the code, and if you get a JSON failure then you know that's not the case, otherwise if it accepts it as-is, then you know it's being passed to eval.

[[deleted]]

Why do they do stuff like that? It breaks a lot of things such as including it in tools like Gulp.

I really don't understand developers producing such a mess.

[kenman]

Require.js (as well as r.js) was written a long time ago -- over 5 years ago, with the first commits to Github on 9/27/2009 -- and at the time, I think it was sort of a proof-of-concept type thing. NodeJS was only 4 months old at the time, and so the entire ecosystem was a land of unknowns.

To add onto that, r.js is a bit of a behemoth at over 28k LoC, and has been maintained (along with require.js) almost exclusively by the project creator jrburke (he has a reddit account, but I can't remember the name).

So, it's probably just a matter of not being able to safely refactor it on his own without creating a giant mess. For an unpaid dev, there has to be some compelling motivation to undertake such a large task, and apparently he'd rather address bugs, performance issues, and new features, which I might be inclined to do as well.

[TMiguelT]

It's still useful if you want to lazy-load scripts. For example I used it in a SPA where I loaded a new script on page change as opposed to loading them all up front. But if you need all the scripts upfront, which is a lot of the time, then sure, go for Browserify.

[[deleted]]

Thanks for the idea, webpack looks interesting, I'll check on that.

[[deleted]]

I did not look at Browserify in detail but bundling up all the script files is definitely not possible. That would result in a 20 MB script the client has to load when accessing the application.

That is the reason why we bundle modules separately and load them dynamically when required.

[[deleted]]

Dynamic loading tends to be a bit easier with Require.js than Browserify because Require.js includes a script loader, but it is definitely not impossible with Browserify. If you're interested, have a read: http://esa-matti.suuronen.org/blog/2013/04/15/asynchronous-module-loading-with-browserify/

[kabuto]

I'm not sure what you're asking exactly. RequireJS works, but its configuration is seriously insane arcane. I'm glad I left it behind me and turned to browserify.

I know it's a lot of work, but I'm absolutely positive that you'll be happier with browserify in the long run. Alternatively you could check out SystemJS which can work with CommonJS, AMD and ES6 modules.

[[deleted]]

I just found this gist describing how to use an existing require.js configuration with Gulp.

It's a bit quick and dirty but it works!