Strange behavior with `expand` and `cwd`

[vitalets]

hi, I'm using newer for jshint task and got strange behavior. It works fine with following config:

    grunt.config('jshint', {
       all: {
            expand: true,
            //cwd: 'src',
            src: 'src/background/*.js'
        }
...
grunt.registerTask('lint', ['newer:jshint']);

but if I uncomment cwd and change src to relative path - it always think that files changed and runs jshint over them:

    grunt.config('jshint', {
       all: {
            expand: true,
            cwd: 'src',
            src: 'background/*.js'
        }
...
grunt.registerTask('lint', ['newer:jshint']);

always get >> 1 file lint free. for grunt lint

Did someone have the same issue and how to solve it? I'm on macos.

[tschaub]

I can see the same behavior. The expand option is supposed to be used to generate src:dest mappings. Even though you don't specify any dest files, Grunt converts your config into one containing dest files (when grunt.task.normalizeMultiTaskFiles is called). Because these dest files are never generated, the newer task thinks it needs to use all src files every time.

The quick solution is not to use expand (or cwd). I'm curious if there is some reason you need to use expand with your jshint config. Please reopen if you can provide some more detail on why expand is needed in this case - I could put in a workaround to handle cases like this.

[vitalets]

hi @tschaub thanks for reply! the usecase for cwd is optimization of config: we have constant SRC pointing to sources (that differs for different projects) and very similar grunt configs with cwd: SRC.

[joaocc]

Well, I also came across this "bug-like" behaviour today. We want to generate a single file (a zip) from a set of files in "dir1/dir2/many-other-distinct/*.txt", so we thought of using cwd to shorten the string (removing the common folder prefix).

Is there any way to propose an improvement to support this scenario (multiple files specified with expand/cwd) and a single target file?

Thanks

[tschaub]

To handle tasks that are configured with expand but don't really generate dest, the newer task would have to decide if the original task config actually had any dest-type config. Internally the newer task calls grunt.task.normalizeMultiTaskFiles, which is a way of "normalizing" all of the various flavors of file configuration that Grunt supports. When this function encounters expand, it automatically generates dest values.

So this request is basically about supporting the degenerate expand cases (places where expand is used but dest files are not specified). This comes down to two forms:

someTask: {
  someTarget: {
    files: [{
      expand: true,
      cwd: 'so/much/less/typing'
      src: '**/*.js'
    }]
  }
}

and

someTask: {
  someTarget: {
    expand: true,
    cwd: 'so/much/less/typing'
    src: '**/*.js'
  }
}

Both of these "expand" to a files array like this:

[{
  src: 'so/much/less/typing/one.js'
  dest: 'one.js'
}, {
  src: 'so/much/less/typing/two.js'
  dest: 'two.js'
}, {
  src: 'so/much/less/typing/three.js'
  dest: 'three.js'
} /** etc. */]

The challenge for the newer task would then be to determine which one of these was not supposed to have a dest entry. In the examples above we have three items in the response from grunt.task.normalizeMultiTaskFiles and only one corresponding "file config" in the original - so it wouldn't be too bad. But in general you could have any number of entries in the original files array and any other number in the normalized array. Deciding which came from where is non-trivial.

The second form above (no files array, just expand, src, and cwd properties) would be easier to deal with. In this case, all dest values in the normalized files array could be stripped out. So supporting this form but not the other (expand members within a files array) could be possible.

Any other suggestions?