You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe the problem you're trying to solve.
Currently, a remote-theme is downloaded and discarded for every build session.
This is wasteful when a user runs multiple jekyll build commands; each gap involving a change to an entity that is not going to regenerate with Jekyll's --watch option.
For example, changes to the config file or a local plugin.
Additionally, if a user is requesting for a fixed version of a remote-theme, e.g. owner/name@sha or owner/name@branch, having to spend bandwidth (albeit very little per request) is not ideal.
Describe the solution you'd like
A config setting to explicitly declare consent for persistence (irrespective of remote_theme value pointing to HEAD):
Enable persistence automatically based on the presence of the git_ref component in remote_theme value
Describe alternatives you've considered
Resort to installing the gem-version of themes that provide them.
Clone theme repositories and add a gemspec file to them when gem-versions are not provided.
Additional context
This could be a welcome option for support teams servicing multiple clients using the same version of a theme
Additional design consideration
Configuration to set up global or local caches. (Similar to how npm or yarn packages are managed).
Global caches could be set up inside user's HOME directory.
Local caches (per project) could be set up within vendor/cache/ which is already ignored by Jekyll 4.x
Configuration to bust caches when desired.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe the problem you're trying to solve.
Currently, a remote-theme is downloaded and discarded for every build session.
This is wasteful when a user runs multiple
jekyll build
commands; each gap involving a change to an entity that is not going to regenerate with Jekyll's--watch
option.For example, changes to the config file or a local plugin.
Additionally, if a user is requesting for a fixed version of a remote-theme, e.g.
owner/name@sha
orowner/name@branch
, having to spend bandwidth (albeit very little per request) is not ideal.Describe the solution you'd like
A config setting to explicitly declare consent for persistence (irrespective of
remote_theme
value pointing toHEAD
):or
Enable persistence automatically based on the presence of the git_ref component in
remote_theme
valueDescribe alternatives you've considered
Additional context
This could be a welcome option for support teams servicing multiple clients using the same version of a theme
Additional design consideration
Global caches could be set up inside user's HOME directory.
Local caches (per project) could be set up within
vendor/cache/
which is already ignored by Jekyll 4.xThe text was updated successfully, but these errors were encountered: