build.bootstrap could take grunt.initConfig obj as param

[andrewk]

This would prevent the need for "call grunt.initConfig first!" warnings in the docs. build would simply call grunt.initConfig internally.

build.bootstrap({
    paths: {
            css: {
                src: 'src/scss',
                dist: 'dist/css'
            },
            js: {
                src: 'src/js',
                dist: 'dist/js'
            }
        }
});

[xzyfer]

I see what you're getting it here but it only solves half the grunt.initConfig issue.

There a couple problems here:

1. Users expect to call grunt.initConfig in their Gruntfile, and all of the internet tells them that's what they should be doing it
2. Calling grunt.initConfig resets all existing config, so either we nuke their config, or they nuke ours.

Calling build.bootstrap after the consumer's config has been set also has many benefits such being able to detect what plugins they're using so we can do the minimum amount of interfering.

This doesn't mean we can't still pass the paths object into bootstrap, but we'd then also need to pass it into the getSassLoadPaths and getRequireJSComponents methods as well.

All in all to be safe build.bootstrap needs to be call as late as possible in the grunt bootstrapping process. It'd be great if grunt supplied this mechanism.

[andrewk]

Sure, I figured there would be complexities.

My real point is that comments of "dont do this or bad things will happen!" is a failing of the API. Build tools already has access to the grunt module, can it inspect grunt to see if its received its config and exit gracefully (with a meaningful error message) if it has not?

[xzyfer]

Build tools already has access to the grunt module, can it inspect grunt to see if its received its config

I'm not sure I'm following. The only mechanism we have for determining what plugins are being used, is simply inferring it from the config that's been set. So if build.bootstrap is called before the config is initialised we have no information to base our decisions on.

For example if an application is already using sass in Gruntfile, then they're almost certainly going to have something like this:

grunt.initConfig({
  sass: {
    dist: {
      files: [{
        expand: true,
        cwd: 'styles',
        src: ['*.scss'],
        dest: '../public',
        ext: '.css'
      }]
    }
  }
});

If you call build.bootstrap before that grunt.initConfig there's no way for use to determine if you're already using sass. If we were to go ahead and set our sass config, the impending grunt.initConfig would overwrite what we just set.

---

I agree it's not ideal. A possible solution is to clone the config, and reinitialise it with the old values. I'm fairly sure it'll work, but I'm not confident there won't be unintended side effects. It's worth looking into and should probably be it's own ticket.