Changes being made to CSS file not being seen by Jekyll Serve (watch) about jekyll-watch HOT 14 CLOSED

Is Gulp not changing the mtime of the file?

from jekyll-watch.

@pathawks Wow, I think that's what it is: gulpjs/gulp#2193

lol, that's a "feature" of Gulp 4 apparently. Thanks for helping me track this down. I assumed that this was a Jekyll issue because the change to the file was being made. Thanks again!

from jekyll-watch.

that's a "feature" of Gulp 4 apparently.

That's a lousy feature, IMO...

from jekyll-watch.

@sebnitu Your src folder has been listed under the exclude: configuration. So files inside it will not be "watched" by the plugin. The onus is therefore on Gulp (or Node JS) to watch the sass source files and output it to dist/css which will be picked up by Jekyll and this plugin..

from jekyll-watch.

It's not suppose to build from the src folder. Those are the files Gulp uses to create dist/css. I'm saying that when changes are made to dist/css/styles.css by Gulp, it does not get picked up by Jekyll's watch. I've confirmed that Gulp is correctly changing the contents of styles.css, but it is not being copied to _site.

from jekyll-watch.

I made a quick video to show you what I mean: https://cl.ly/cb510b6e9330

from jekyll-watch.

@sebnitu Does Jekyll pick up changes when made manually to dist/css/styles.css..?

from jekyll-watch.

Yes, if I manually make changes to dist/css/styles.css , the file does get picked up by Jekyll. It's only when Gulp 4 generates the file that it's not getting seen.

from jekyll-watch.

"lousy feature" is a matter of perspective - it's a goal to have gulp.src().pipe(gulp.dest()) to be equivalent of the cp command, which is what you are seeing. Most tools don't rely on mtime to trigger watchers so this is an edge case. That being said, node's fs.Stats object is severely lacking and we want/would need to implement an entire BetterStats module to handle this appropriately - unfortunately no one has any interest in helping us out so users need to add a "touch" transform in their pipelines for these edge cases.

Issue: gulpjs/vinyl#105

from jekyll-watch.

@phated The reason this was frustrating for me was because it's functionality that was removed from the previous version of Gulp. From the perspective of a Gulp user, this was very unintuitive because you would think that if Gulp is modifying a file it would update mtime. Isn't that the entire point of that property? Also, it's not consistent because if you save a Sass file from the file with the imports, it DOES update mtime, only when you save from a partial it doesn't. So to then be told that this is suppose to be a "feature" is hilarious and frustrating.

If I was smarter and knew how to implement this type of functionality, I would. But I'm not. I literally use Gulp because I don't know how to do this stuff.

from jekyll-watch.

@sebnitu a major version has major changes and has been included far longer than 4.0 has been published. This functionality is documented in our brand new documentation at https://gulpjs.com/docs/en/api/dest#metadata-updates - you must have missed it.

from jekyll-watch.

@phated Yes, I have read that part of the docs while I was transitioning to Gulp 4 this past week and that tells me nothing about the issue I ran into. In fact, that exact explanation told me that the issue must be with Jekyll because it says: "If they differ, the created file will be updated to reflect the Vinyl object's metadata".

But you know, if it makes you feel better to make me feel stupid instead of just accepting that this was a very frustrating experience instead of getting defensive because I decided to give you folks feedback, that's fine. Good luck with that.

from jekyll-watch.

@sebnitu Honestly, entitled people like you make open source absolutely miserable to work on. Thank you for raining shit upon my weekend! 🎉 🎉

from jekyll-watch.

@phated My apologies for sounding insensitive when I said the feature was "lousy"

from jekyll-watch.