Suggestion: Modify a separate config object

[marrs]

I see from the docs that this plugin modifies the current requirejs.config (if present) and tries to be non-destructive about how it does that. This means, amongst other things, that if you remove a package from bower, it won't be removed from the config.

Can I suggest a different approach: modify a separate config that the user then overrides.

var autoConfig = {
  paths: {
    // This always maps directly to whatever
    // components are installed via bower.
  }
}

require.config(extend(autoConfig, {
  // My rules go here.
}));

This ways it's obvious what grunt is in control of and what I the developer am in control of.

[robdodson]

You can point the task's rjsConfig option at a separate config file and it'll still work. Would that solve your problem?

[marrs]

Thanks for the quick response.

That depends on how two or more require configs combine. It would work if the 2nd config overrides the 1st such that require.config({a: 'foo', b: 'bar'}); require.config({b: 'baz'}); is equivalent to require.config({a: 'foo', b: 'baz'});.

If the 2nd require config replaces the 1st, then it wouldn't help. I don't remember off the top of my head how requirejs handles more than one config.

[robdodson]

I believe it'll merge the two, with the second one overriding values in the first. My brain was in Node.js land when I wrote that first comment.. I see now what you originally wanted. You want a variable in the config file that the task would write to and then you want to extend that. I'll have to think about that. It might make the task a bit more complex than we want..

[robdodson]

@sindresorhus what do you think? it's an interesting idea... I've noticed on my current project that once you start relying on the task it is easy to accumulate some cruft when you remove things and forget to cleanup the config.

[KidkArolis]

I agree separating the generated config from the manual config is a good idea.

2 separate files is not a bad idea, for example, bower_components could be a nice place to keep the generated config (not possible in 0.10 yet). However when 2 files are used, both dynamic loading and building process become more complicated.

For dynamic loading, you have to somehow load both config files before proceeding with loading the app. I've tried doing the following:

require.config({
  // my config 
});

require(['../bower.config'], function () {
  require(['main']);
});

The problem with the above is that I'm loading the 2 configs in the wrong order - it should be possible to override bower.config with my config. I could do

require(['../bower.config'], function () {
  require(['../my.config'], function () {
    require(['main']);
  });
});

But now it's a bit strange to be doing so many sequential requests (1 for this boot.js, 2 for the configs and finally 1 for the main app). Not sure this is a real problem.

Another problem with the above approaches is that building the app with r.js becomes more complicated. I usually use the mainConfigFile r.js option to reuse my configuration. But if 2 files are used - I'm not sure how that could get built. `mainConfigFile' currently doesn't accept arrays of files, but that could be improved (https://github.com/jrburke/r.js/issues/406). Alternatively, you'd probably have to concatenate the 2 config files programatically, but that doesn't sound very end user (bower end user) friendly.

Keeping the 2 configs in 2 separate objects within the same file is also a nice idea. However, there might be problems with optimizing as well. Dynamic configs and multiple calls to require.config are not allowed in r.js atm https://github.com/jrburke/r.js/issues/481.

Ideally, I would like all of the required bower component config to be created in a separate file (including shim (e.g. backbone) and package (e.g. when) configs ;) and it should be really simple to include that config in your project so that you can just start requiring things in your project with no manual config (like you do in node).

[sindresorhus]

I like the idea of separating them, but from the above comment I'm not sure it's feasible atm.

[KidkArolis]

mainConfigFile can now be an array of config files (http://jrburke.com/2014/01/08/requirejs-2.1.10-released/) making a separate "bower_components/amd.config.js" a possibility.

[sindresorhus]

Anyone wanna do a PR?

[morficus]

I know this is an old(ish) issue but I would like to re-visit this. Mostly because of what @robdodson mentioned above

I've noticed on my current project that once you start relying on the task it is easy to accumulate some cruft when you remove things and forget to cleanup the config.

Here is my suggestion: In place of having to load 2 config files in your application, how about having a reference config file which gets merged with the generated file (where ref config file takes precedence over what ever is automatically generated, as @marrs mentioned above). To specify the ref config file use the -rc (or --ref-config) option with a file path or a config file in JSON format.

If this sounds kosher, I could take a stab at opening a PR for this some time next weekend (and then the grunt plugin, once the PR gets merged in)