Open jcoyne opened 2 years ago
@jcoyne can you help me understand what supporting propshaft would entail? Is this a matter of updating the capistrano-rails REAMDE with some guidance on what value propshaft users should use for :assets_manifests
, or is it a more fundamental code change?
@mattbrictson I imaging it would just add a new pattern in here: https://github.com/capistrano/rails/blob/082255af014d9d3f777489faa1081d6c8e3f74d0/lib/capistrano/tasks/assets.rake#L139 that matches the manifest that Propshaft uses: https://github.com/rails/propshaft/blob/793a20e74201cd6c97f22fb8df75f353e7aebe5b/lib/propshaft/processor.rb#L4
I've done this and it works as a workaround:
set :assets_manifests, -> {
[release_path.join("public", fetch(:assets_prefix), '.manifest.json')]
}
But now that propshaft is included by Rails, it makes sense to make this a default part of capistrano-rails.
I have set in config/deploy.rb
:
set :assets_manifests, -> {
[release_path.join("public", fetch(:assets_prefix), '.manifest.json')]
}
as advised.
And this works well with propshaft
.
Similar to #235, when using propshaft rather than sprockets
the
deploy:assets:backup_manifest
task fails because propshaft makes a manifest named:public/assets/.manifest.json
which does not match the existing patterns in:assets_manifests