As @envygeeks suggested in #5341 I am opening an issue to discuss an approach to themes that would satisfy most requirements that have been stated after the basic theme support was released:
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.
So basically, a theme will be 'sucked' into the build process of a site and whenever the site provides a file with the same relative path as the one provided by the theme, the site's one is to be used.
It would at least solve the problem with theme assets, with or without jekyll-assets.
/cc @jekyll-core @envygeeks
As @envygeeks suggested in #5341 I am opening an issue to discuss an approach to themes that would satisfy most requirements that have been stated after the basic theme support was released:
Why not have a
_config.ymlfor 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.
So basically, a theme will be 'sucked' into the build process of a site and whenever the site provides a file with the same relative path as the one provided by the theme, the site's one is to be used.
It would at least solve the problem with theme assets, with or without
jekyll-assets./cc @jekyll-core @envygeeks