Process only new/changed files

[macbookandrew]

Is it possible to run the tasks only on new/modified files? I currently have 10 emails in my src/emails folder, and it takes ~30 seconds to run all the tasks on every file.

I toyed around with http://grunt-tasks.com/grunt-newer/ and prepending newer: to the default tasks in aliases.yml, but it didn’t seem to make any difference.

Any ideas?

Thanks for the workflow!

[leemunroe]

👍

Makes sense. I'll definitely look into it.

[macbookandrew]

@leemunroe I found grunt-newer-explicit and it seems to be working better. Here’s a PR with changes that should work…I’ve modified a bunch of other settings in my working repo, but I think this is enough to get this working.

Also note that I removed clean from the default grunt task…seems at odds with the grunt-newer approach, but it’s up to you.

[macbookandrew]

The more I think about this, it’s not going to work well.

First run

1. Save a *.hbs file
2. The template is assembled
3. The output is juiced
   So far, so good

Subsequent runs

1. Make some more changes
2. The templates are all assembled again because juice modified them
3. The output files are all juiced again because they’ve been reassembled

Without an intermediate location to save assembled output before juice-ing it to the final location, I’m not sure how to make this work. Any ideas?

[leemunroe]

@macbookandrew Did you ever find a good solution for this?

[macbookandrew]

@leemunroe Not really; I ended up modifying the grunt/juice.js file with a wildcard src and just updating it as necessary for newer files:

    files: [{
      expand: true,
      src: ['<%= paths.dist %>/*2016-08*.html'],
      dest: ''
    }]

[taeo]

This is definitely a complicated. I think there's some refactoring/options to watch that can make this better and faster.

• scss changes should trigger scss, assemble, juice, and replace tasks for all templates.
• layouts, partials, and data changes should trigger assemble, juice, and replace tasks for all templates.
• img changes should trigger only imagemin task

Taking it a step further, it's possible to incorporate something like the following that would process only a subset of src/emails/ templates.

grunt watch:specific --files="filename_or_pattern"

grunt build:specific --files="filename_or_pattern"

[macbookandrew]

@taeo I like the idea. Unfortunately I’m not fluent enough with gulp to build those changes without taking a whole day to do it 😄

[taeo]

No worries. I'll give this a spin when I have a second. I'm currently trying to wrap up #87 if you have any opinions or desire to help test that out.

[taeo]

Hey @macbookandrew

I just pushed up a fork on my branch for build times and options. It addresses build times as well as watch related options.

It's not "automagic" unfortunately, but here's a use case that would only watch for and process:

• template updates matching the name *2016-08*.
• scss updates get compiled, but only applied to the afore mentioned templates
• (Any layouts, data, or partials trigger a complete rebuild of all templates)

grunt preview --template="*2016-08*"

Additional grunt option --noinline can be passed if you don't want css styles inlined (will be preserved in <style> tag.

grunt preview --template="*2016-08*" --noinline

Let me know if you're willing to give the branch a spin and provide any thoughts, feedback, or questions.

[leemunroe]

@taeo Sweet. Give it a good test and works a treat! 🎉

[taeo]

Solid. Thanks for testing!

There's a little tidying up and README updates to make. Other than that, should we give it a little time and prompt a few more people to test, or just go PR and done?

[leemunroe]

Maybe give it a few more days in case @macbookandrew has time to try it out. Curious if it solves his problem. But it LGTM to PR.

[macbookandrew]

@leemunroe @taeo Thanks! I just got back from vacation. Hopefully I can test this out in the next few days, but don’t hold it just on my account.

[taeo]

@macbookandrew - welcome back! Hope you had a good vacay. No rush here. Would love to have input + further testing to see if it meets your needs and is easy enough to use this way.

[taeo]

Closing based on forthcoming PR from feature/build-times-and-options