Caching the compiled CSS makes sense 99% of the time, but I recently ran into a situation where it's better to have it disabled: Using TailwindCSS in JIT mode. Jekyll will recompile the CSS every time any file is changed, but the caching is preventing TailwindCSS from running to actually update the CSS.
An overview of what happens in this case with caching enabled might help explain it better:
Jekyll is started and PostCSS runs, compiling and caching the CSS.
You change a class name in an HTML file.
Jekyll recompiles the HTML and CSS, but PostCSS is not run and the cached CSS is used.
The new class name has no effect since it's not added to the CSS.
Other Changes
I included two other small changes, one is a bug fix for using TailwindCSS and one is a small tweak:
I removed the stdin source in bin/postcss. This was throwing an error when using TailwindCSS. A workaround is to create an stdin file in the root, but this seems more sane. This fixes #22. (See 5fa94692).
I slightly tweaked the cache_miss method to help it read a bit better with the cache disabled condition.
Let me know if you'd prefer the the bin/postcss as a separate PR and I can split them up.
Caching the compiled CSS makes sense 99% of the time, but I recently ran into a situation where it's better to have it disabled: Using TailwindCSS in JIT mode. Jekyll will recompile the CSS every time any file is changed, but the caching is preventing TailwindCSS from running to actually update the CSS.
An overview of what happens in this case with caching enabled might help explain it better:
Other Changes
I included two other small changes, one is a bug fix for using TailwindCSS and one is a small tweak:
stdinsource inbin/postcss. This was throwing an error when using TailwindCSS. A workaround is to create anstdinfile in the root, but this seems more sane. This fixes #22. (See 5fa94692).cache_missmethod to help it read a bit better with the cache disabled condition.Let me know if you'd prefer the the
bin/postcssas a separate PR and I can split them up.