SCSS regeneration is not working when changing imported files

[icalvo]

When running the server with preview, I can get the SCSS to regenerate only if I change the main SCSS file (I am using a modified Clean Blog so that would be clean-blog.scss). Also importantly I have to disable the cache in the browser web tools.

However, if I change any SCSS imported by the main file, that doesn't work. The server realizes that a file has changed and starts all the process, but when it comes to generating the CSS file:

Assets/Output » WriteFiles » Skipped writing file C:/Users/ignacio.calvo/Repos/StatiqTest/src/CommandLine/output/scss/clean-blog.css from C:/Users/ignacio.calvo/Repos/StatiqTest/src/CommandLine/theme/input/scss/clean-blog.scss because it already exists and the content is the same

So I have to touch clean-blog.scss (just add or remove some char) for this to work.

I understand why this works like this: the app doesn't know that clean-blog.scss depends on other files. However, is there a way to provide this file dependency to the pipeline? I also think it'd make sense for Statiq.Web to regenerate all SCSS files every time some SCSS file changes.

[daveaglick]

However, is there a way to provide this file dependency to the pipeline?

I don't think that would work generally, Statiq doesn't have a way of following when the SCSS processor follows file includes, and manually figuring out a SCSS dependency graph is likely too much to ask of a user, especially since it would have to be kept up to date and would create confusion if and when it falls behind.

I also think it'd make sense for Statiq.Web to regenerate all SCSS files every time some SCSS file changes.

This is probably a workable mitigation. It likely stands to reason that if there are any "ignored" SCSS or Sass files in the input directory (typically indicated by the lack of an underscore prefix), that they're intended to be used with the primary ones (without underscores) as includes. It seems totally reasonable that if we see any input file change with a SCSS extension, even if it's prefixed by an underscore, we should reprocess any SCSS files that might include it.

Let me see if this is an easy enhancement...

[daveaglick]

An update that fixes this will go out in the next release. It hooks the file watching bit to invalidate any Scss/Sass file whenever any other Scss/Sass file changes.

Happy you pointed this out - it's long been an annoyance of my own, and I just hadn't done the groundwork to see if it was mitigatable. Turns out it wasn't that tricky.

[icalvo]

Thank you very much. I this applies also to LESS and it will come up again for any language processed by Statiq pipelines that is able to import files (maybe Handelbars?)

[daveaglick]

Possibly - it depends pretty heavily on how includes are handled by the particular engine and whether we can integrate tightly enough to provide Statiq documents in a virtual file system or not. For the Scss processor, we have limited integration points, so it actually goes out an finds includes on its own in the actual local file system. This isn't great for a number of reasons (Statiq modules aren't supposed to care or interact with the actual physical file system, their view of the world should ideally be entirely document-driven). This issue is one result of that lack of integration because we don't ever "load" those included files into Statiq as documents, so the caching logic doesn't know the calling Scss file should be invalidated because all the caching is based on document content.

In other words, modules with tighter integration should be change-aware because included content is represented by Statiq documents instead of raw files, and the caches should (ideally) get invalidated when included content changes. It might still be an issue with the Less processor though, I'll check to make sure.