grunt.task.current.name

[tkellen]

When we support running tasks concurrently, accessing this property is going to be a problem. I have an idea for a solution but I'm not sure what it should look like.

Instead of doing this:

concat: {
  options: {
    banner: '<%= grunt.current.task.name %>'
  },
  targetOne: {
    src: 'test/fixtures/files/*.js',
    dest: 'tmp/concat.js'
  },
  targetTwo: {
    src: 'test/fixtures/files/*.js',
    dest: 'tmp/concat.js'
  }
},

We could do this:

concat: {
  options: {
    banner: '<%= parent.parent.name %>'
  },
  targetOne: {
    src: 'test/fixtures/files/*.js',
    dest: 'tmp/concat.js'
  },
  targetTwo: {
    src: 'test/fixtures/files/*.js',
    dest: 'tmp/concat.js'
  }
},

The options-merged form would be this, which would resolve to targetOne

concat: {
  targetOne: {
    options: {
      banner: '<%= parent.parent.name %>'
    },
    src: 'test/fixtures/files/*.js',
    dest: 'tmp/concat.js'
  },
}

The question I have is what is the best way to implement this introspection?

@cowboy / @shama ?

[cowboy]

sweet jesus

[tkellen]

Sweet jesus what?

[cowboy]

Hmmn.. I thought we'd resolve the concat.options.banner string where it was defined, as it's first extracted from the config, not after options merging. I don't like the idea that with "relative" properties, the value can mean different things based on when in the process of options merging it might be evaluated.

[tkellen]

Yeah, you would want to pull it directly from where it is. Now that I think of it, I might be able to perform this traversal myself using the current syntax. I updated expander today to support explicitly defining imports that are available in _.template: https://github.com/gruntjs/grunt-next/blob/master/runner/index.js#L28-L34

Perhaps I can make grunt.task.current.name a getter that does some magic to find out where it is when it is gotten.

[cowboy]

Keep in mind, there's also grunt.task.current.target, grunt.task.current.args, grunt.task.current.flags, etc.

[tkellen]

blah. i guess a closure around the imports for template expansion is going to be the solution.

[tkellen]

actually, adding introspection into expander could be cool, though. any thoughts on a reasonable non-confusing syntax?

[cowboy]

I like the idea where you could access an array of path parts based on where you currently are, maybe (a) __path inside a template string is an array of all the parts leading up to and including the current key eg, __path[0]. Maybe (b) instead of an array it's a function that accepts an index value like __path(0) or even __path(-1) to go from the right side. Maybe (c) we have some namespace under which other similar utility things live. Maybe all the things.

{
  foo: {
    bar: {
      baz: '<%= __path[0] %>'   // 'foo' (a)
      qux: '<%= __path(1) %>'   // 'bar' (b)
      bla: '<%= __.path(-1) %>' // 'bla' (c)
    }
  }
}