Incremental regeneration

[fw42]

Does this gem work with Jekyll 3 and the new incremental regeneration feature? I'm getting all my assets deleted (but not rebuilt) on every regeneration cycle (except the initial one). Is this a bug or am I doing something wrong?

@parkr, any idea?

[parkr]

I don't know! I haven't worked with this plugin before. A bunch of internals have changed since 2.x so it's very possible that this will break.

I'd suggest rewriting the monkey-patches as hook plugins.

[blimey85]

This gem is working great for me as I'm on Octopress 2.x using Jekyll 2.x but you might want to look at the new AssetPipeline gem for Octopress 3. I believe Octopress 3 is now compatible with Jekyll 3 and all of the new Octopress is designed to be able to run on top of Jekyll meaning you should be able to use any of the pieces (gems) on their own. You can find it here: https://github.com/octopress/asset-pipeline if you're interested. Might be worth a try.

[envygeeks]

I have the same question, have any of you ran into any problems with this because we need something that can digest assets for a new client project and I'm sick of maintaining our own asset plugin so I came here looking for this one but we use Jekyll3 throughout our entire cluster.

[ixti]

I have a plan to refactor jekyll-assets to utilize maximum of Jekyll 3 API (as well as update to latest sprockets and so on and so on -- grand refactoring that will be close to rewriting it from scratch I believe), but currently lack of time. Hope I will find some on this weekend. But can't promise anything.

[ixti]

Anyone willing to help, welcome aboard! :D

[razor-x]

This asset plugin is so much better then any of the other asset handlers I've seen for other static generators so far (even the new Jekyll one). It's handled every use-case I can throw at it.

Moving the rest of this comment to a separate issue to avoid derail: #155.

[envygeeks]

After having taken a look at both this source, the way that it behaves and the logic behind it's behavior this thing needs a rewrite in the logic before it can even begin to integrate with regeneration.

1. It does not respond to the necessary methods that @alfredxing expects. It has it's own pathname and modified? methods... these come from Sprockets, we can fix that in Jekyll no problem, because those are common methods and we should probably facilitate that.
2. It does some kind of weird unnecessary optimization that seems to only load static assets after they are used. This is very unexpected behavior and needs to change, those assets need to exist early so that their change can trigger a change can trigger a rebuild. This is an easy fix, use a hook and if we do not provide that hook, ask for it. That way you can load your assets early. If you wish to only write if they are used, make that an option, make it a setter and have a boolean getter to determine whether to write but I don't understand why that would even exist in the first place, it makes it hard to have hashed assets that are there for general purpose inclusion.

[envygeeks]

If I'm honest though, I would opt to rewrite it because a lot of this can be achieved with a fraction of the code given people take advantage of the way Jekyll behaves, duplicate a few base methods from Jekyll and let the regeneration take care of the rest.

[j15e]

Yeah I think too we could rewrite this with a fraction of the code. I am thinking of ways we could architect this better but haven't completed a plan yet.

Right now im doing this in my _plugins/ext.rb to rebuild the assets I need on each devepment rebuild which kind of mimic the rails-sprockets default to precompile some assets :

Jekyll::Hooks.register :site, :post_write do |site|
  # It just works™ (hacky way to precompile while I find a better solution)
  ['styles.css', 'default.js'].map do |asset|
    site.assets[asset].write(site.dest)
  end
end

Plus this fix to avoid jekyll 3 removing all the assets : https://github.com/didacte/jekyll-assets/commit/3d1ace7cadd380afda28bf5b0503197eda716299

[envygeeks]

The only problem I have (I'm using master) is that it will not regenerate the entire site if there is an asset change, assets do get notified of their need to write (on my Linux system -- with current jekyll-assets master) they do not however trigger a full rebuild of the entire site if there is an asset change because it doesn't preload assets so there is no way for me to shiv regenerate and check for the asset's modification to force a rebuild.

[j15e]

To avoid having to re-build all pages (because of fingerprints) when assets changes in development I am also adding this patch in my plugins/_ext.rb to keep fingerprints in production build but not development server :

Jekyll::Hooks.register :site, :pre_render do |site|
  if Jekyll.env == 'development'
    site.assets_config.cachebust = :none
    site.assets_config.js_compressor = nil
    site.assets_config.css_compressor = nil
  end
end

[envygeeks]

And hooks come to the rescue :+1: for that workaround, thanks. I didn't even think of that >.>

[envygeeks]

Here is my version using sprockets 3 with support for incremental regeneration: https://github.com/envygeeks/ruby-jekyll3-assets - If you guys want I'm willing to hand over this code to jekyll-assets and make it Jekyll2 compatible (thought I don't know if that's even worth it) but this was built because we were running into the same problems as @fw42 and we needed something that relied more on environment mixed with options for things like compression and we wanted transpiling our ES6 so Firefox would stop being horrible and autoprefixing... both of which were not supported easily on Sprockets2.

Either way, if you guys want to get together I'm happy to hand this over to jekyll-assets.

[j15e]

@envygeeks nice work! thanks for sharing. I am using Jekyll3 too so no plan to make it Jekyll2 compatible on my side.

[envygeeks]

The temporary https://github.com/jekyll-assets/jekyll3-assets repo has full support for Jekyll3 (as previously mentioned) and will be merged into this in the next week as I bring the parity up so that nobody gets taken by surprise when it's merged in.