Why copying the assets?

[jacob-carlborg]

Why are the assets being copied? I haven't seen any other plugin that uses the assets pipeline that does this. The copy command generates some output which capistrano shows as errors.

[spohlenz]

The number one reason is for performance -- TinyMCE contains a lot of files that, when added to the asset pipeline, must be run through the compressor on each precompile. However these files come from upstream precompressed which makes this step redundant.

Here are the times for rake assets:precompile on the sandbox app (contained within the source), with the Sprockets compilation and with copying as it is now:

Asset compilation with Sprockets, upstream files unchanged

~/Development/tinymce-rails/sandbox(master) $ time be rake assets:precompile
/Users/sam/.rvm/rubies/ruby-1.9.3-p362/bin/ruby /Users/sam/.rvm/gems/ruby-1.9.3-p362/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets

real    1m44.512s
user    1m16.333s
sys 0m3.643s

Asset compilation with Sprockets, precompressed files from upstream replaced with their uncompressed versions

~/Development/tinymce-rails/sandbox(master) $ time be rake assets:precompile
/Users/sam/.rvm/rubies/ruby-1.9.3-p362/bin/ruby /Users/sam/.rvm/gems/ruby-1.9.3-p362/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets

real    1m14.692s
user    0m55.863s
sys 0m2.992s

Asset compilation with asset copying

~/Development/tinymce-rails/sandbox(master) $ time be rake assets:precompile
/Users/sam/.rvm/rubies/ruby-1.9.3-p362/bin/ruby /Users/sam/.rvm/gems/ruby-1.9.3-p362/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets
mkdir -p /Users/sam/Development/tinymce-rails/sandbox/public/assets
cp -rp /Users/sam/Development/tinymce-rails/vendor/assets/javascripts/tinymce /Users/sam/Development/tinymce-rails/sandbox/public/assets

real    0m48.593s
user    0m36.108s
sys 0m1.967s

As you've seen, this approach has it's drawbacks. What you've seen with capistrano is output from rake that can safely be ignored, but there are worse problems such as #83.

Ideally, Sprockets would provide a way to not recompress certain files. For now it's a trade-off I'm happy to debate further.

[jacob-carlborg]

I see. Almost one minute slower, that's not good. I see no reason why Sprockets would need to recompress the files if they're not changed, If I recall correctly Sprockets generates a hash of the contents of the files to know if the files are changed. Perhaps it needs to do that every time to compare with the old hash.

[spohlenz]

The new Sprockets coming with Rails 4 has some improvements in this area, so I'll likely revisit this when it is properly released.