organizing assets

[ha404]

Does anyone think it's worth organizing all the paths for sources and dests in a single object?

var bases = {
  app: 'app/',
  dist: 'dist/',
};
var paths = {
  scripts: ['scripts/**/*.js', '!scripts/libs/**/*.js'],
  libs: ['scripts/libs/jquery/dist/jquery.js', 'scripts/libs/underscore/underscore.js', 'scripts/backbone/backbone.js'],
  styles: ['styles/**/*.css'],
  html: ['index.html', '404.html'],
  images: ['images/**/*.png'],
  extras: ['crossdomain.xml', 'humans.txt', 'manifest.appcache', 'robots.txt', 'favicon.ico'],
};

Example use:

gulp.src(paths.styles, {cwd: bases.app})
  .pipe(gulp.dest(bases.dist + 'styles'));

*I just copied this from an article I found: http://www.justinmccandless.com/blog/A+Tutorial+for+Getting+Started+with+Gulp

This could possibly make things easier to update whenever someone wants to perform an upgrade in the future?

[silvenon]

Thanks for the suggestion, I thought about it a few times, but each time I realized that paths will differ from task to task. For example, sometimes you might perform a task on all HTML files and sometimes you'd like to exclude 404.html or something similar.

Unlike Gruntfile.js, in a gulpfile.js paths aren't so repetitive and adjusting to a new directory structure should be much easier. In a gulpfile.js actions are applied to the stream in a single go, where in a Gruntfile.js your paths would be repeated over and over again for each task. For example, I can see that images and extras paths would most probably be used only once, so using the values directly actually results in less code.

All in all, I see little room (and reason) for automation in that area. If a specific setup worked for you much better, feel free to share it 😃

[austinpray]

For this:

var paths = {
  scripts: ['scripts/**/*.js', '!scripts/libs/**/*.js'],
  libs: ['scripts/libs/jquery/dist/jquery.js', 'scripts/libs/underscore/underscore.js', 'scripts/backbone/backbone.js'],
  styles: ['styles/**/*.css'],
  html: ['index.html', '404.html'],
  images: ['images/**/*.png'],
  extras: ['crossdomain.xml', 'humans.txt', 'manifest.appcache', 'robots.txt', 'favicon.ico'],
};

I thought about it a few times, but each time I realized that paths will differ from task to task. For example, sometimes you might perform a task on all HTML files and sometimes you'd like to exclude 404.html or something similar.

Sure.

For this:

var bases = {
  app: 'app/',
  dist: 'dist/',
};

There is no reason to not do this. I do this on every gulpfile I make. Especially when bases with vinyl get complicated.

[silvenon]

In my opinion it decreases readability for very little gain. You can change those with search & replace.

[austinpray]

In my opinion it decreases readability for very little gain.

What is not readable about variables? This is exactly what variables are for.

[kalenjohnson]

@austinpray I forget what bases.app and bases.dist are.

[ha404]

Variables are good for storing repetitive code, so if your gulpfile.js uses a lot of the same base paths to your assets, it's probably good to store it there and just change it once depending on your project's spec.

All this can be stored and replaced with a base path:

[silvenon]

Variables are convenient if changing their value will save time. In this case a simple search & replace for app/src/ will do the trick.

What is not readable about variables? This is exactly what variables are for.

Variables are usually for making the code shorter and more flexible. This will not make the code shorter and, in my opinion, not that flexible either.

bases.app + 'scripts/**/*.js'
// vs
'app/scripts/**/*.js'

The former is less readable and takes longer to type.

[silvenon]

This is just my opinion, I'll wait for others from the team to share theirs 😃

[ha404]

@silvenon, agreed, it's only when app/src becomes unwieldy in @austinpray's case. I have yet to encounter this and it seems like the majority of us don't run into this use case so I'm going to close this up and settle it until one day we reach a time when this becomes useful.

[ha404]

Forgive me, I just realized why I initially thought this was a good idea again.

Please, ring in on your thoughts: Imagine I wanted to just update to the latest version of gulp-webapp.

I'd have to surgically go through every single task (making sure I don't miss one) to update the path to my assets whereas I could just copy over the old paths object and that'll just be that.

Would this be desirable?

[silvenon]

I previously had a hunch that it might be, but realistically if you want to change app/styles to app/src/styles, you could do it with a search & replace and there would probably be max 3 occurrences, which would take you like 15 seconds to change manually. Paths in gulpfile.js aren't really that repetitive, I think, and variables can be a drag to type and concatenate.

I never felt a need to do this (unlike in a Gruntfile.js). Did you? Also, I don't think updating a gulpfile.js would be a matter of simple file replacement, as you probably modified some stuff, so you would have to adapt it manually anyway.

Do you have a use case where updating paths wouldn't be simple without variables?

[silvenon]

I feel it's more clear without using variables. Because paths in gulpfile.js are not very reusable, sometimes you want app/scripts/**/*.js, sometimes you want app/scripts/vendor/**/*.js, or maybe app/scripts/**/*.jsx. It depends on what you want in that particular case, and I don't think that creating a variable for each variation is not useful, it just requires an additional lookup.

I think this is more a matter of taste than actual usefulness. Closing this.