CMS becomes unuseable with module installed

[chillu]

It brings the standard admin/pages load from 1s to around 6s on my local, and adds this overhead to every ajax request in the CMS. Even for "dev mode", that's not acceptable.
And this will become more noticeable now as more people will have the module installed through composer install --dev (see silverstripe/silverstripe-installer@71b8b658).

In the end, we should only trigger compass if relevant files are changed.
One relatively straightforward way would be to track file modification times of all *.scss files.

I haven't actually been using the module for a while now, doing compass watch on CLI instead.
Hamish, are you still an active user?

[halkyon]

Myself and others have switched to compass watch instead, it's less obtrusive and you can see what it's compiling in the command line ;-)

[wilr]

I don't even bother with the module anymore. The one nice thing that it does is build all scss files from the modules (rather than having to watch each folder) but I've moved to a gruntjs based system for that as well (replacing requirements::combine_files with grunt as well)

[hafriedlander]

I use it on client projects, but not when working on SilverStripe.

Just a note though: compass already checks modification times & caches the compiled css. I'm not sure how much we'd save checking timestamps outselves. We could disable the recompile on AJAX calls though, or possibly hook into Requirements::css instead of per request.

[chillu]

If the called compass binary does some modification time checks which should prevent it from doing a full reparse, it's either faulty or overwritten by our specific usage. You can easily test this by refreshing the CMS multiple times without any usage of flush - it takes 5s+ each time.

For now, I think we should remove it as a core dev dependency: silverstripe/silverstripe-installer#25

[halkyon]

Agreed, and merged.

[sminnee]

Personally, I like this module and I think that having a way of running compass without keeping a separate daemon running in the background is a useful benefit - we have this whole requirements manager, it seems silly not to use it when SCSS is such a fundamental part of the way we do things.

The barrier to entry is a higher without this module - running compass watch inside each module sounds like a pain in the arse, and I'm also not sure whether or not it's documented.

Once this issue is resolved, I'd like to see us include this back in the dev dependencies. This module is, in principle, a "set & forget" system for SCSS, in the same way that requirements minification is.

What do you mean by "less obtrusive", Sean?