Closed macbookandrew closed 6 years ago
:+1:
Makes sense. I'll definitely look into it.
@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.
The more I think about this, it’s not going to work well.
First run
*.hbs
fileassemble
djuice
d
So far, so goodSubsequent runs
assemble
d again because juice
modified themjuice
d again because they’ve been reassemble
dWithout an intermediate location to save assemble
d output before juice
-ing it to the final location, I’m not sure how to make this work. Any ideas?
@macbookandrew Did you ever find a good solution for this?
@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: ''
}]
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 taskTaking 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"
@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 😄
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.
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:
*2016-08*
. 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.
@taeo Sweet. Give it a good test and works a treat! 🎉
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?
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.
@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.
@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.
Closing based on forthcoming PR from feature/build-times-and-options
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!