search

mickleroy / aem-sass-compiler

Enable Sass support for AEM
Other
49 stars 18 forks source link

Sass files not getting live compiled #4

Closed mutukrish closed 7 years ago

mutukrish commented 7 years ago

Hi,

I perfectly followed the documentation given and my .scss files are getting compiled. But when i change some styles in components/_tabs.scss (example), the changes are not getting compiled.

mickleroy commented 7 years ago

Hi, Thank you for letting me know about this issue. I was able to reproduce it on my environment so I will investigate and update this issue accordingly.

Work around A work around whilst a solution is found is to trigger the invalidation of the client library manually using http://localhost:4502/libs/granite/ui/content/dumplibs.rebuild.html?invalidate=true.

Issue details When updating a Sass file within a sub-directory that isn't the main Sass file, it does not trigger the invalidation of the cache for the corresponding client library. The expected output in the log should be similar to this:

com.adobe.granite.ui.clientlibs.impl.LibraryCacheImpl Invalidating library /etc/designs/aem-sass-compiler/clientlib-less
com.adobe.granite.ui.clientlibs.impl.HtmlLibraryManagerImpl detected [CSS] library: /etc/designs/aem-sass-compiler/clientlib-less, sourced from 6 files.
com.adobe.granite.ui.clientlibs.impl.LibraryCacheImpl Rebuilt 2078 ancestor paths

However, this is not happening so when requesting the compiled CSS file, the client library is not rebuilt.

LJ-837194 commented 7 years ago

Hi Michael,

Thanks for your reply. Another work around that we tried is that, we just modified some class in the main.scss that will invalidates the cache and the changes done in the sub directory SASS files are getting reflected. Will wait for your next milestone release for the fix.

Many thanks Michael for your reply. Really appreciate it !!

mickleroy commented 7 years ago

Just an update on this issue...

When an update is performed to a file within a client library, the HtmlLibraryManagerImpl checks whether that file is a dependency of a registered client library category. However, there seems to be a difference in the dependencies property of the cached CSS created by the clientlibs-service under /var/clientlibs.

Less /var/clientlibs/etc/designs/aem-sass-compiler/clientlib-less/generated/sample.css/jcr:content

dependencies=[/etc/designs/aem-sass-compiler/clientlib-less/partials/_base.less,
        /etc/designs/aem-sass-compiler/clientlib-less/file.less,
        /var/clientlibs/etc/designs/aem-sass-compiler/clientlib-less/generated]

Sass /var/clientlibs/etc/designs/aem-sass-compiler/clientlib/generated/sample.css/jcr:content

dependencies=[/var/clientlibs/etc/designs/aem-sass-compiler/clientlib/generated]

You'll notice that with the Sass clientlibs, the dependencies property does not contain the original scss files under /etc/designs/. I have not been able to figure out why that is yet.

A less elegant solution would be to register my own event listener and force the HtmlLibraryManagerImpl cache to be flushed.