New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/asset folder support for themes #5341

Closed
ashmaroli opened this Issue Sep 8, 2016 · 13 comments

Comments

Projects
None yet
4 participants
@ashmaroli
Member

ashmaroli commented Sep 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Sep 8, 2016

Contributor

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

Contributor

benbalter commented Sep 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashmaroli

ashmaroli Sep 8, 2016

Member

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 ?

Member

ashmaroli commented Sep 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 8, 2016

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.

ghost commented Sep 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 9, 2016

Contributor

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.

Contributor

envygeeks commented Sep 9, 2016

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 comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 9, 2016

Contributor

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.

Contributor

envygeeks commented Sep 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vwochnik

vwochnik Sep 10, 2016

Contributor

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.

Contributor

vwochnik commented Sep 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 12, 2016

Contributor

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

Contributor

envygeeks commented Sep 12, 2016

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

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Sep 12, 2016

Contributor

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.

Contributor

benbalter commented Sep 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vwochnik
Contributor

vwochnik commented Sep 12, 2016

@benbalter benbalter changed the title from [Discussion] Gem based themes and assets to /asset folder support for themes Sep 15, 2016

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Sep 15, 2016

Contributor

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.

Contributor

benbalter commented Sep 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Sep 15, 2016

Contributor

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?

Contributor

benbalter commented Sep 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 15, 2016

Contributor

I'm okay with 3.3.

Contributor

envygeeks commented Sep 15, 2016

I'm okay with 3.3.

@benbalter benbalter added this to the 3.3 milestone Sep 15, 2016

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Sep 20, 2016

Contributor

Implemented in #5364.

Contributor

benbalter commented Sep 20, 2016

Implemented in #5364.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment