Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Improve convertor support for compiling dynamic assets #708

Closed
imathis opened this Issue · 15 comments

6 participants

@imathis

Right now Jekyll's converter runs everything through the templating system and requires all files to have a YAML header. This is a pain for dynamic assets and it would be better if there was a type of convertor which would process these without requiring them to have a YAML header and without passing them through the templating system. Assets should not need access to template variables and it would be unfortunate if their contents inadvertently triggered Liquid processing errors.

Ideally Jekyll would have template converters and asset converters. A possible alternative is that converters should only be used to process templates and Jekyll should use some other method to coordinate asset compilation.

@parkr
Owner

I'm strongly :+1: for this. This would (mostly) solve the two issues cited above this comment.

@parkr
Owner

What do you think, @mojombo, @qrush?

@qrush

I don't get what the problem is here. You can have SCSS or whatever in your directory and not have a YAML header.

https://github.com/OpenHack/openhack.github.com/blob/master/assets/index.scss
https://github.com/coworkbuffalo/coworkbuffalo.github.com/blob/master/assets/food.coffee

You're then responsible for compiling this stuff, not Jekyll. Jekyll's job is slightly dynamic site generation via HTML and Liquid. I don't see why we're confusing that with other things.

@agarie

@qrush I think that the problem is the need of a YAML header for dynamic assets that should be treated as static files.

I use LESS in my personal blog, simply by running a rake task that calls lessc. This way, I don't use YAML headers in the less files (inside a _less directory) and the css files created are copied as simple static files to the destination. Obviously this process isn't handled by Jekyll, but I can use Guard or the watch command to automate this.

Is there any way to reorganize the "jekyll pipeline" to handle this kind of process? For example, hooks between each step in which you can select if your plugin works on a StaticFile, Page or Site.

@qrush

But you don't need a YAML header at all for most files...that's what I'm confused about. Why would you need to add one for a file that doesn't need processing via Liquid? Jekyll should ignore processing any files without a header and just copy them into the _site directory.

As for the "pipeline" that's a messy, huge issue that I honestly don't feel Jekyll was designed for or prepared to handle.

@imathis

@qrush I see lots of folks using the converters to manage preprocessing assets. Since converters require the YAML header I thought it might be nice to add a type of converter which was designed to handle asset compilation instead of just templates. I figured this was a cow path that wouldn't be too hard to pave, but if that's not something that you feel like Jekyll should do, I'm fine with that.

@imathis imathis closed this
@qrush

@imathis Can you show me an example of a converter with a YAML header? Just paste or a gist. I guess that might help.

@imathis

@qrush In the plugins wiki, under the Converters section it states:

Please note that Jekyll will only convert files that also have a YAML header at the top.

Here's an example of a coffeescript converter where the author makes note that Coffeescript files must have a YAML header to be picked up by the converter.

@parkr
Owner

@qrush I wrote a very similar plugin this summer for CoffeeScript and Compass compilation integration into a Jekyll project for work, and nothing was processed properly (compiled) without the YAML header. Instances of StaticFile are not sent through the plugins to the best of my ability, and without the YAML header, that's what these asset files are.

@qrush

That's pretty messed up. I guess I haven't used any plugins or converters but this seems pretty broken.

@parkr
Owner

I believe static_file.rb#L58 confirms that StaticFile instances are merely copied (not converted or anything) from source to destination.

@parkr
Owner

I'll see what I can do over the next couple days in terms of a PR for this issue. Should clear up any questions.

@ixti

I'm not quiet sure which problems you might experience. I wrote a plugin some time ago: jekyll-assets and it allows work with assets same as we do in Rails3+: you can write your assets in CoffeeScript, SASS, Less, dynamically generate them with ERB, concatenate bunches of files into one using special "//= require" directives, so that you can have a proper dependencies graph and minify them.

@imathis

@qrush yeah it is pretty messed up, if this is something Jekyll should support. Right now having Jekyll convert non-template assets using converters is just a bad idea. I'd love better support from Jekyll but since it's possible (though inelegant) to handle this externally, if this feature is put on the back burner I'd be okay with that. I don't want something like this to be a burden on Jekyll development.

I will say that generating assets externally is really hard when using Jekyll's auto compilation since any time any file is saved the whole site gets regenerated. For folks with lots of posts, it takes very long time. I'd love it if #705 were addressed to make it easier for preprocessors to work alongside Jekyll.

@matthodan

I know this issue has been closed, but the Jekyll Asset Pipeline plugin addresses the YAML header issue and caches the processed assets so they are not re-processed unless something changes. The way I see it, this is the best of both worlds-- dynamic links to processed assets via Liquid tags and no wasted cycles reprocessing assets that haven't changed. I could be missing something...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.