/asset folder support for themes

[ashmaroli]

Hi,
I'm creating a new gem-based Jekyll theme. It uses an assets directory alongside the regular scaffolding.
I'm aware that Jekyll doesn't currently support this feature.

I was wondering.. why can't Jekyll expand its scope to include assets as well along the similar lines _layouts, _includes and _sass have been incorporated.

How would this affect JekyllAssets plugin?

/cc @jekyll/ecosystem, @envygeeks

[benbalter]

Nice. Thanks for opening this @ashmaroli. This has been on my mind for a while to open.

See #4510 (comment) and related discussion with @envygeeks.

IIRC, where the discussion landed, would be to add an /assets folder in the theme, which would be included in the resulting site. The folder could include static files (images, fonts, etc.) but also Pages (e.g., /assets/style.scss, /assets/app.coffee).

From Jekyll's perspective, the logic would be that for every file that existing in the Theme's assets folder, we'd first look to see if the file already exists in the site (to support the site maintainer's ability to override any file, and also not to clobber existing files). If the file doesn't exist, we copy it from the theme, into the existing site, and render it like we would any other file.

From a theme maintainer's perspective, this would allow them to package images, fonts, and other static assets with their theme.

From a user's perspective, this would solve the problem of needing to create /assets/style.scss before using a theme, as that could be an auto-include-if-it-doesn't-exist page.

/cc @jekyll/ecosystem

[ashmaroli]

I'm patiently awaiting the day this becomes a reality.

From Jekyll's perspective, the logic would be that for every file that existing in the Theme's assets folder, we'd first look to see if the file already exists in the site

Would this extra 'thinking and acting' greatly slow down jekyll's site generation and regeneration ?

[ghost]

Would this extra 'thinking and acting' greatly slow down jekyll's site generation and regeneration ?

@ashmaroli We can assume the implementation will do so in a linear time to the amount of assets being used, rather than the amount of content. So the performance damage shouldn't be too large.

[envygeeks]

Having "/assets" affects us none, other than we would overwrite said files if both were installed as we assert ourselves pretty aggressively over Jekyll to guard our own concerns... so if you have _assets/css/main.scss and /assets/main.css you would only get the processed version of _assets/css/main.scss -> /assets/main.css because we'll walk all over Jekyll.

Now if Gem based themes supported say "_assets" and had the folders we had and downstream (Jekyll Core's plugins) understsood those and could disable themselves with a configuration option, at that point we would update Jekyll Assets to disable the internal SASS/Cofeescript processing and do it for you, enabling our advanced asset management. That is what I would like to see and something I am happy to implement if the world is fine with that because then everything can work in tandum, I can build the same tags here in core (or in a core-plugin that is default), and Jekyll Assets can simply disable the core stuff and boom, everything is just magic at that point.

[envygeeks]

This would all need to come in 4.0 though, this is not a 3.x change, well it could be but it's better suited for 4.

[vwochnik]

why not have a _config.yml for each theme containing include and exclude where every file other then _*-prefixed directories is being read into a StaticFile with the ability for a site including this theme to provide their own version, a.k.a. overriding?

Also, config files can then include the plugins the theme depends on making Jekyll automatically load those to support the build process of the theme.

[envygeeks]

@vwochnik I like that idea and I think it should be it's own feature ticket!

[benbalter]

This would all need to come in 4.0 though, this is not a 3.x change, well it could be but it's better suited for 4.

@envygeeks Can you explain why /assets theme supports could be 3.3? (minor bump)

Now if Gem based themes supported say "_assets" and had the folders we had and downstream (Jekyll Core's plugins) understsood those and could disable themselves with a configuration option

Sounds like /assets (versus /_assets) is the better option then. As an added bonus, it would allow the theme to be built/previewed locally without any intervention.

[vwochnik]

#5350

[benbalter]

Some discussion in #5341 (comment), but to summarize, this issue is a feature request for theme's to support a /assets folder. The idea would be that any file in that folder would be read in, as if it were part of the site, unless the file exists in the source site. This would include Pages like scss files, which would alleviate the need for the user to create /assets/style.scss with an @import statement before they could use the theme. It would also include static files like images or javascript.

[benbalter]

I like this feature a lot and think it will greatly improve the theme user experience. For both users and developers. For developers, the Theme remains a working Jekyll site, and for downstream users, it removes a step such that themes can work out of the box. Any objection to targeting this for 3.3?

[envygeeks]

I'm okay with 3.3.

[benbalter]

Implemented in #5364.