adding "nodigest" task to add non digest assets

[celsodantas]

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

[rafaelfranca]

Cool! The implementation looks good to me. Lets document it now. Could you add it to the README?

[celsodantas]

I removed the previous files params for the task so we can accept multiple params comma separated like:

rake 'assets:generate_nondigest[file1.js, file2.js, folder with space/app.js]'

The args.extras will split it by ,.

Should I go back to task :generate_nondigest, [:files] => :environment and do the split in the task?
Will have a little more code in the task but might be a little easier to understand that the task need params. thoughts?

[rafaelfranca]

I don't remember how the command looks like with the files parameter, sorry. Could you post here?

[celsodantas]

The command would be similar but AFAIK we can't pass arrays to rake tasks, so with the files params:

task :generate_nondigest, [:files] => :environment do |t, args|
  split_files = args[:files].split ', '
  ...
end

And the command would be:

rake "assets:generate_nondigest['file1.js, file2.js, folder with space/app.js']"

But as you can see, we'll need to pass it as a string and split it. Code would start to get a little hairy as we'd need to make sure variations in the passed string (with different spaces counts) would still need to be correctly parsed if we decide to support folder names with spaces.

If we don't support folder with spaces, we could drop the , in the string and only do a files.split(' '):

task :generate_nondigest, [:files] => :environment do |t, args|
  split_files = args[:files].split ' '
  ...
end

And the command would be:

rake "assets:generate_nondigest['file1.js file2.js folder_no_space/app.js']"

Whatchathink?

[rafaelfranca]

I think the explicit argument would be better.

[celsodantas]

done =)

[celsodantas]

updated the README as well to not include , but only spaces in the params

[celsodantas]

Documentation added to README.

[josh]

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.

[celsodantas]

@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).

[matthewd]

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.)

[celsodantas]

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 notifications@github.com 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
#239 (comment)
.

[rafaelfranca]

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']?

[rafaelfranca]

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?

[streetlogics]

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.