What if this.file.src (inside tasks) was already expanded? #532

Closed
cowboy opened this Issue Nov 15, 2012 · 10 comments

Comments

Projects
None yet
3 participants
Owner

cowboy commented Nov 15, 2012

Right now, inside of tasks we have a lot of this kind of thing:

var files = grunt.file.expand(this.file.src);
files.forEach(...);

What if this.file.src was already expanded (using grunt.file.expand), and this.file._src was made available as the unexpanded array of source patterns, in case someone really needed it?

var files = this.file.src;
files.forEach(...);

And because of the way the grunt.file.expand* methods work, this should still work, since each expanded file is just a pattern that matches one specific file:

var files = grunt.file.expand(this.file.src);
files.forEach(...);

FWIW, I'm thinking of nuking grunt.file.expandFiles and grunt.file.expandDirs, see #531.

Owner

tkellen commented Nov 15, 2012

Yes, yes and yes! This is exactly the direction I was hoping to go. I'm not sure I see the value in adding _src though. If a task writer wants to do something special, they can grab the raw config value and go to town?

Member

sindresorhus commented Nov 15, 2012

YES! I actually suggested that to @tkellen a week ago or something.

Owner

cowboy commented Nov 16, 2012

@tkellen, if the task author grabs the raw config value, there is no way for them to know which files sub-object the task is currently iterating over. All they know about is the task and the target names.

Since there would be no way for them to actually get the right src value, it has to be made available to them in the this.file object.

It doesn't need to be called _src though. Maybe the raw files list should still be called src and the expanded files list should be called something else. I'm not 100% in love with _src (raw) and src (expanded).

Ideas?

Owner

tkellen commented Nov 16, 2012

Ah, good point.

Hmm. Well, practially speaking I have no idea what the use case is for
wanting it un-expanded? Maybe leave it out until someone asks for it?
YAGNI.

Also, the task format is going to change so drastically for 0.5 that it
doesn't seem like a super important detail now.

On Nov 16, 2012, at 1:18 PM, Ben Alman notifications@github.com wrote:

@tkellen https://github.com/tkellen, if the task author grabs the raw
config value, there is no way for them to know which files sub-object the
task is currently iterating over. All they know about is the task and the
target names.

Since there would be no way for them to actually get the right src value,
it has to be made available to them in the this.file object.

It doesn't need to be called _src though. Maybe the raw files list should *
still* be called src and the expanded files list should be called something
else. I'm not 100% in love with _src (raw) and src (expanded).

Ideas?


Reply to this email directly or view it on
GitHubhttps://github.com/gruntjs/grunt/issues/532#issuecomment-10456422.

Member

sindresorhus commented Nov 18, 2012

I would like expanded source to be called src since it's the most useful one. Maybe just call it something succinct like rawSrc.

Owner

tkellen commented Nov 19, 2012

srcRaw works for me, but I really do think we should finish the docs and get 0.4 out the door before we spend time adding new features.

Member

sindresorhus commented Nov 19, 2012

I agree, pri1 should be to get 0.4 released.

Owner

cowboy commented Nov 19, 2012

The reason I was doing this was because I had to go through all the tasks again dealing with the this.files -> this.file changes and got annoyed.

I'm going to merge this in because it works. I'll change the property name to srcRaw first.

Owner

tkellen commented Nov 19, 2012

Awesome! I'll yank needless expansion from tasks when it is in.

cowboy closed this in 5d6cb51 Nov 19, 2012

Owner

cowboy commented Nov 19, 2012

FWIW, the concat task is an example of where we need to custom-expand the raw src array:

https://github.com/gruntjs/grunt-contrib-concat/blob/7578040dd98441c3354bc4926c1d1ddb439905d1/tasks/concat.js#L32-L34

It may be useful to think about some sugar for this kind of thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment