allow for any option to be passed to grunt instead of just the 3 expected ones

[bdwain]

it'd be nice to be able to pass any option we wanted to grunt through the options object.

[bdwain]

this can be done just by remove the if hasOwnProperty block when reading the options

[maxov]

Do you mean passing options to http://gruntjs.com/api/grunt.option? If so, I would think this would better be in another object, since the main object right now is just for gulp-grunt configuration.

[maxov]

When brainstorming a better API, I came up with this:

var grunt = require('gulp-grunt');
// Create a gruntfile instance
var gruntfile = grunt({ 
  file: 'path-to-gruntfile',
  opt: {
   force: true // grunt options
  }
});

See #3 (comment). Thoughts?

[bdwain]

i'm a little unclear how this would work with the current gulp-grunt pattern. wouldn't the gruntfile object need to be passed into the call to require(gulp-grunt) or something?

[maxov]

Further in #3 I gave some examples:

// register a task
gulp.task('grunt-build', gruntfile.run('build'));

gruntfile.tasks() // still returns the tasks hash
gruntfile.register(gulp, {
  prefix: 'some-prefix'
  // use options like the current version
});

Essentially, the gruntfile is an object that represents the actual gruntfile. It means you can have multiple gruntfiles referenced in a single gulpfile, and also register tasks without polluting your namespace. The last method, register, functions like gulp-grunt does currently.

[bdwain]

oh sorry i didnt see that. I feel like if you have to register tasks manually then what exactly does this plugin do besides add another layer on top of the grunt api? My thought was that it was a convenient way of calling grunt tasks without knowing the grunt api at all, but this would still require learning the gulp-grunt api.

[maxov]

@bdwain In this API schema, gulp-grunt would allow a single gulpfile to run tasks from multiple grunt files. It would do this by spawning child processes, managing different tasks, and ensuring correct error-handling capability. This is not a trivial set of requirements. I don't follow the last thought, gulp-grunt already has an API, this would just extend it with support for multiple gruntfiles. In addition, it reduces the dependency on gulp. And the last function .register mirrors the current API, so updating a gulpfile basically takes a one line modification.

[bdwain]

@gratimax I see the value now. Thanks for explaining. I like that design, though the name gulp-grunt would start to be come misleading, since it seems like it's moving away from a pseudo-gulp plugin to a gruntfile manager.

[maxov]

@bdwain Indeed. However, it will still provide gulp-specific facilities for attaching grunt tasks to the gulp task runner, as it does now. In that way it will still stay somehow gulp-specific.

[bdwain]

ok. well yea i think that makes sense and is a good way of allowing a generic list of options to be passed.