sprockets-rails
sprockets-rails copied to clipboard
rails
adding "nodigest" task to add non digest assets
Problem
This gem does not generate non-digest files anymore.
A lot of apps still need the non-digest because some of their assets belongs to an SDK that they need to serve it outside of their application (e.g. like what Shopify does). For that they need to have a constant URI for their assets.
There's alternative like the non-stupid-digest-assets but I feel like this should be built-in as it's a more common pattern.
Solution
Just copy existing files without the digest part of the name.
Limitation
As we are not recompiling the file, any external file reference (image references) will still contain digested references. This is not a problem as the use case for this feature is to use the asset file as part of a SDK to be served to other developers, so references to digested files are OK.
But, but... what about cache expiration?
That's a different problem for the developer to solve per asset file. The idea behind this is to enable the developer to generate a few non-digested files, not to serve the entire application assets.
As this not rake task is not run by default during assets:precompile the cache issue is another problem. This is an explicit action for a common and punctual problem.
cc @rafaelfranca @arthurnn for discussion Related: #49
Cool! The implementation looks good to me. Lets document it now. Could you add it to the README?
Do we really want to design an API around passing paths to rake arguments like this?
Won't you always be deploying with the same set of non-digest dependencies?
Writing non-digest files to /assets may interfere with manifest GC process. Wouldn't it make sense to put them some place else.
How are people going to configure separate caching semantics with these assets. They can't live forever with max-ago=10000000.
@josh this is separate rake task to copy compiled files without the digest. Why would this interfere with manifest GC process?
Wouldn't it make sense to put them some place else.
Where? This is basically copying files in the /public folder. This command is to be ran after you have compiled your files already and should be ran during the deploy process. Just like rake assets:precompile
How are people going to configure separate caching semantics with these assets. They can't live forever with max-ago=10000000.
As said in the PR description, the cache expiration is different problem. This task is not the default task (but a complimentary one) and there's a brief explantation in the README telling devs that is their responsibility to deal with cache for those files. Also, that's the reason you need to explicitly pass all the files you want to get non-digest, so ppl don't overuse this.
The use case for this is for JS/CSS SDKs. Files that you need to have access from outside of you application and need to have public access. See the Shopify's example.
Also another fact that this is a feature that people want is the non-stupid-digest-assets having a lot of people using it (186k+ downloads in rubygems).
IMO, if you're publishing a well-known URL for a thing, you're better off serving it via the router and a controller. That way you have full control of caching policies, etc.
Now, it's separately true that we don't currently make it terribly easy to have an action that's basically "render the current latest contents of asset X", so I'm not claiming this is a solved problem... but I'm personally not keen on endorsing this particular solution for the described use case.
I guess I see "assets" not as "JS, CSS, etc" but as "supporting material for the application": if you have an Actually Important Thing On A URL, I'm unconvinced it's a mere "asset", regardless of what MIME type it's returning. (And yes, even if you're using the asset pipeline to assemble it.)
You can still have control of the assets policies from the assets server configuration (that's what we do at shopify).
I don't see great benefits from serving these assets (they are static files) from a controller.
On Monday, May 11, 2015, Matthew Draper [email protected] wrote:
IMO, if you're publishing a well-known URL for a thing, you're better off serving it via the router and a controller. That way you have full control of caching policies, etc.
Now, it's separately true that we don't currently make it terribly easy to have an action that's basically "render the current latest contents of asset X", so I'm not claiming this is a solved problem... but I'm personally not keen on endorsing this particular solution for the described use case.
I guess I see "assets" not as "JS, CSS, etc" but as "supporting material for the application": if you have an Actually Important Thing On A URL, I'm unconvinced it's a mere "asset", regardless of what MIME type it's returning. (And yes, even if you're using the asset pipeline to assemble it.)
— Reply to this email directly or view it on GitHub https://github.com/rails/sprockets-rails/pull/239#issuecomment-100927771 .
Do we really want to design an API around passing paths to rake arguments like this?
Won't you always be deploying with the same set of non-digest dependencies?
Good point about always deploying the same assets.
Maybe we should add a new config option like: config.assets.non_digested = ['foo.v1.js']?
IMO, if you're publishing a well-known URL for a thing, you're better off serving it via the router and a controller. That way you have full control of caching policies, etc.
@matthewd I think we can alo have full control of caching policies even if we skip the router. Also I think serving from the router would make harder to serve these assets from a CDN right?
Maybe we should add a new config option like: config.assets.non_digested = ['foo.v1.js']?
This would definitely follow existing convention better, and then this task could be tied in with the precompile process automatically without having to trigger another call.
