Do not regenerate entire site if StaticFile is updated #705

Closed
parkr opened this Issue Dec 25, 2012 · 4 comments

Projects

None yet

3 participants

@parkr
Member
parkr commented Dec 25, 2012

One big headache with regeneration is that even if some static file is changed (not a Page or a Post), the entire site is regenerated.

It'd be cool if there were a way to more specifically target site regeneration (i.e. only regenerate if Page or Post is changed) instead of always regenerating.

More discussion in #692, but post new comments here.

@imathis
Contributor
imathis commented Dec 26, 2012

I agree, it would be nice if static files were simply copied to the site directory, rather than triggering a full regeneration. However that calls into question how Jekyll defines static files. It would seem that Jekyll defines a static file as any file without the YAML header, since Jekyll's converters will only process files with ---\n---\n at the top.

I think this distinction is fairly limited since it requires every file to have a YAML header to be passed through Jekyll's converters. In #708 I propose adding support for compiling dynamic assets instead of treating any converted file like an html template. If this is accepted, dynamic assets (like Sass or Coffeescript) won't require a YAML header and deciding what constitutes a static file may be a bit more complicated.

Perhaps rather than using Jekyll's YAML header to divide dynamic and static files, we could say that any file which doesn't get matched by a converter will simply be copied to the compiled site directory instead of triggering a recompile.

@parkr
Member
parkr commented Dec 27, 2012

Perhaps rather than using Jekyll's YAML header to divide dynamic and static files, we could say that any file which doesn't get matched by a converter will simply be copied to the compiled site directory instead of triggering a recompile.

I think this is the way to go.

@kevinSuttle

+1

@parkr
Member
parkr commented Mar 19, 2013

This would require a lot of reconfiguring of DirectoryWatcher. We're looking into a more iterative generation approach for after 1.0.

@parkr parkr closed this Mar 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment