Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sass files not getting live compiled #4

Closed
mutukrish opened this issue May 22, 2017 · 3 comments · Fixed by #7
Closed

Sass files not getting live compiled #4

mutukrish opened this issue May 22, 2017 · 3 comments · Fixed by #7

Comments

@mutukrish
Copy link

mutukrish commented May 22, 2017

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
Copy link
Owner

mickleroy commented May 23, 2017

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.

@mickleroy mickleroy added the bug label May 23, 2017
@mickleroy mickleroy modified the milestones: 1.1.0, 1.0.2 May 23, 2017
@LJ-837194
Copy link

LJ-837194 commented May 24, 2017

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 mickleroy modified the milestones: 1.0.3, 1.0.2 Jul 18, 2017
@mickleroy
Copy link
Owner

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.

Volune pushed a commit to Volune/aem-sass-compiler that referenced this issue Aug 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants