Skip to content
This repository has been archived by the owner on Jan 9, 2019. It is now read-only.

refactor less/stylus/sass support #43

Open
willkg opened this issue Mar 12, 2013 · 3 comments
Open

refactor less/stylus/sass support #43

willkg opened this issue Mar 12, 2013 · 3 comments

Comments

@willkg
Copy link
Collaborator

willkg commented Mar 12, 2013

There are a lot of preprocessors out there and currently support for them is hard-coded into jingo-minify. This really needs a better solution.

At a minimum, it should get abstracted out. Maybe allow for plugin support for additional things so we don't have to maintain them all, too.

@willkg
Copy link
Collaborator Author

willkg commented Mar 12, 2013

SASS and Stylus support is pretty similar. The LESS support has an additional LESS_PREPROCESS thing.

In refactoring we should figure out whether to keep that functionality or ditch it. I'm inclined to ditch it for reduced complexity.

@cvan
Copy link
Collaborator

cvan commented Mar 12, 2013

yeah, I'd be a fan of ditching it. we're removing LESS_PREPROCESS from zamboni any day. (it's too slow for development.)

@pmclanahan
Copy link
Collaborator

django-compressor provides base classes for "filters" which you can subclass and thereby provide your own processing for whatever you want. I like this approach a lot. We create classes for which ever we want out-of-the-box support for, accept pull-requests for others, and allow people to easily define their own. We could auto-import a specific module name in apps (a la helpers.py for jingo), maybe minifiers.py, and auto-register classes to file extensions via metaclass. It's a common django pattern, and should be a lot easier on us.

from django.conf import settings

from jingo_minify.minifiers import BaseCompiler


class StylusCompiler(BaseCompiler):
    type = 'styl'
    bin = getattr(settings, 'STYLUS_BIN', 'stylus')
    command = '{bin} < {infile} > {outfile}'

That along with some hook methods for overriding could get us pretty far. The ones django-compressor has are fairly complex at this point, but I'm not sure ours would need to be.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants