Enhance asset symlinking for webpack assets

[justin808]

• added test cases to spec/dummy
• updated some gems

---

This change is

[justin808]

@alleycat-at-git Please review.

Dev mode works

foreman start -f Procfile.static

then go to http://localhost:3000/css_images_fonts

production does not

RAILS_ENV=production rake assets:precompile
rails s -e production

then go to http://localhost:3000/css_images_fonts

[coveralls]

Coverage decreased (-0.2%) to 82.128% when pulling 43c2a52 on alleycat-at-git-alexey/replace_symlinks_copy into 20f98d9 on master.

[justin808]

@alleycat-at-git it's a bad thing that tests are passing when this change is not working. Bonus points if you can see a way to test the correct behavior. Another issue is webpack 1.0 vs. 2.0. Possibly we should be doing this differently for webpack 2.0? and only supporting 2.0 with this PR?

[alexeuler]

@justin808 I added a commit that fixes the problems. Didn't have time for bonuses - sorry ) Note that you have to use

RAILS_SERVE_STATIC_FILES=true rails s -e production

To run in production mode without nginx and friends

---

Reviewed 28 of 30 files at r1, 2 of 2 files at r2.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

---

lib/react_on_rails/configuration.rb, line 12 [r2] (raw file):

    if @configuration.symlink_non_digested_assets_regex.present? &&
       @configuration.non_digested_assets_regex.blank?
      puts "[DEPRECATION] ReactOnRails: rename config.symlink_non_digested_assets_regex to "\

We have to be careful here - there are two configs - one in the gem and another in the app. While we have full control over the gem configuration, the point of risk is that app uses old config value - and that's where we put deprecation notice. Do we have access to app config via @configuration?

---

spec/dummy/config/secrets.yml, line 23 [r2] (raw file):

production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"].presence ||
   "8cd24e99fc1b68f6cd1592e4db8c88c2b508dbd12a37dd0cef184eb46aa5e3512f386d02c7a29971b8e34a9daa627642fc4a03b9c49e28f1943ea9028c91ba47" %>

Is this and intentional one?

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Dir.glob(Rails.root.join("client", "app", "assets", "**/")).each do |path|
  Rails.application.config.assets.paths << path.chop
end

This one includes not only folders, but subfolders as well

---

spec/dummy/config/initializers/assets.rb, line 30 [r2] (raw file):

  ]
Rails.application.config.assets.precompile += %w(*.png *.jpg *.jpeg *.gif *.tiff *.woff *.ttf *.eot
*.svg)

I have no idea why - but for some reason pipeline didn't touch those in custom dir. This line solved it

---

Comments from Reviewable

[alexeuler]

Review status: all files reviewed at latest revision, 4 unresolved discussions.

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, alleycat-at-git (Alexey) wrote…

This one includes not only folders, but subfolders as well

BTW like I said - I don't think it's a good idea to do this, that way you'll have x4 copies of the same asset - one generated by webpack, another with rails and x2 each for non-digested copies

---

Comments from Reviewable

[justin808]

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

---

lib/react_on_rails/configuration.rb, line 12 [r2] (raw file):

Do we have access to app config via @configuration?
Yes

---

spec/dummy/config/secrets.yml, line 23 [r2] (raw file):

Previously, alleycat-at-git (Alexey) wrote…

Is this and intentional one?

yes, so testing in production does not require the key.

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, alleycat-at-git (Alexey) wrote…

BTW like I said - I don't think it's a good idea to do this, that way you'll have x4 copies of the same asset - one generated by webpack, another with rails and x2 each for non-digested copies

We should change that then. We can use relative paths.

---

Comments from Reviewable

[robwise]

why are we switching from symlinks to copying? What about cleanup of stale asset files? This was handled elegantly via symlinks because they know when they are broken

---

Reviewed 28 of 30 files at r1, 2 of 2 files at r2.
Review status: all files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

---

.rubocop.yml, line 54 [r2] (raw file):

Metrics/CyclomaticComplexity:
  Max: 9

that's one way to pass the linters

---

lib/react_on_rails/configuration.rb, line 67 [r2] (raw file):

      server_render_method: "",
      symlink_non_digested_assets_regex: /\.(png|jpg|jpeg|gif|tiff|woff|ttf|eot|svg)/,
      non_digested_assets_regex: /\.(png|jpg|jpeg|gif|tiff|woff|ttf|eot|svg)/,

we may also want to put .map type in here for source maps

---

lib/tasks/assets.rake, line 114 [r2] (raw file):

    .enhance do
      Rake::Task["react_on_rails:assets:symlink_non_digested_assets"].invoke
      Rake::Task["react_on_rails:assets:delete_broken_symlinks"].invoke

are you putting in any code to delete the files you've copied to the assets file if they are stale?

---

spec/dummy/client/webpack.client.base.config.js, line 63 [r2] (raw file):

  module: {
    loaders: [
      //{ test: /\.(woff2?|svg)$/, loader: 'url?limit=10000' },

??

---

spec/dummy/client/app/assets/fonts/OpenSans-Light.svg, line 1 [r2] (raw file):

<?xml version="1.0" standalone="no"?>

why are we adding 1000 lines of font svg code, we already have svgs we are testing, I would delete this

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

We should change that then. We can use relative paths.

agree with @alleycat-at-git, this is not necessary, webpack automatically modifies references when it fingerprints assets

---

spec/dummy/config/initializers/assets.rb, line 30 [r2] (raw file):

Previously, alleycat-at-git (Alexey) wrote…

I have no idea why - but for some reason pipeline didn't touch those in custom dir. This line solved it

wait, why is this not reading from our config?

---

spec/dummy/config/initializers/react_on_rails.rb, line 86 [r2] (raw file):

  # For any asset matching this regex, a file is copied to the correct path to have a digest.
  # To disable creating digested assets, set this parameter to nil.
  config.non_digested_assets_regex = /\.(png|jpg|jpeg|gif|tiff|woff|ttf|eot|svg)/

should this be changed to an array of globs so that we can do *.png and get the files in nested folders?

---

Comments from Reviewable

[justin808]

Review status: all files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

---

.rubocop.yml, line 54 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

that's one way to pass the linters

@samnang This is because I want the config file to take the old or new value of a given property. Just adding the additional config value boosted this. Maybe I should set this override locally in the file, @robwise.

---

Comments from Reviewable

[justin808]

@robwise, @alleycat-at-git Please review, especially lib/tasks/assets.rake.

---

Review status: 9 of 24 files reviewed at latest revision, 10 unresolved discussions.

---

Comments from Reviewable

[coveralls]

Coverage remained the same at 82.305% when pulling 40c442f on alleycat-at-git-alexey/replace_symlinks_copy into 20f98d9 on master.

[robwise]

Reviewed 21 of 25 files at r3.
Review status: all files reviewed at latest revision, 12 unresolved discussions.

---

docs/additional-reading/rails-assets.md, line 56 [r3] (raw file):

being processed by Webpack are just MD5's.

• This is too verbose, (as is our entire manual). Every extra line in our docs makes people want to use our gem less. Keep that in mind. Everything added could be replaced with By default, Rails fingerprints all assets in production. Because you are not able to use Rails's asset helpers in your client code, ReactOnRails will automatically make un-fingerprinted versions of these files available. We recommend you still have webpack fingerprint these files itself so that you will still properly bust their respective caches when you change them.
• We shouldn't log non-errors unless some sort of trace or debug mode is on, it's super annoying to have all of the noise we currently do from TestHelper during tests or seeing all of the ReactOnRails context messages in the JavaScript console. If we want to see that, we can turn it on, but most people probably don't want to see all of that (I know @alexfedoseev and I don't)
• Not related to this file necessarily, but also we should only have one trace or debug mode, more than one is super confusing

---

lib/tasks/assets.rake, line 67 [r3] (raw file):

          end
        end
      end

ideally we would move all of this functionality into a PORO using the method_object pattern that can take the paths as arguments so that we can easily test that any of this works, then we simply call that object. Right now we have no coverage of anything happening here and we can't be sure we didn't just regress

---

Comments from Reviewable

[justin808]

We shouldn't log non-errors unless some sort of trace or debug mode is on, it's super annoying to have all of the noise we currently do from TestHelper during tests or seeing all of the ReactOnRails context messages in the JavaScript console. If we want to see that, we can turn it on, but most people probably don't want to see all of that (I know @alexfedoseev and I don't)

Standard Rails does print the fingerprinting, so we should also print the symlinking. I'm OK with skipping the indication that files didn't change.

[justin808]

We recommend you still have webpack fingerprint these files itself so that you will
still properly bust their respective caches when you change them.

I suspect that would be possible but unlikely. The file-loader does this MD5 name by default.

[justin808]

Review status: all files reviewed at latest revision, 12 unresolved discussions.

---

docs/additional-reading/rails-assets.md, line 56 [r3] (raw file):

Previously, robwise (Rob Wise) wrote…

• This is too verbose, (as is our entire manual). Every extra line in our docs makes people want to use our gem less. Keep that in mind. Everything added could be replaced with By default, Rails fingerprints all assets in production. Because you are not able to use Rails's asset helpers in your client code, ReactOnRails will automatically make un-fingerprinted versions of these files available. We recommend you still have webpack fingerprint these files itself so that you will still properly bust their respective caches when you change them.
• We shouldn't log non-errors unless some sort of trace or debug mode is on, it's super annoying to have all of the noise we currently do from TestHelper during tests or seeing all of the ReactOnRails context messages in the JavaScript console. If we want to see that, we can turn it on, but most people probably don't want to see all of that (I know @alexfedoseev and I don't)
• Not related to this file necessarily, but also we should only have one trace or debug mode, more than one is super confusing

Acknowledge this, but I don't want to change any of this now. In terms of verbose messages, Rails says what it's doing when compiling assets, so I want to do the same. There is only one ReactOnRails.trace mode.

---

lib/react_on_rails/configuration.rb, line 12 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

Do we have access to app config via @configuration?
Yes

Done.

---

lib/tasks/assets.rake, line 114 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

are you putting in any code to delete the files you've copied to the assets file if they are stale?

There's no copying. We just add symlinks and delete any broken symlinks. In fact, Rails intentionally does not remove stale assets, as you can have older copy of the page still requesting an older resource.

---

lib/tasks/assets.rake, line 67 [r3] (raw file):

Previously, robwise (Rob Wise) wrote…

ideally we would move all of this functionality into a PORO using the method_object pattern that can take the paths as arguments so that we can easily test that any of this works, then we simply call that object. Right now we have no coverage of anything happening here and we can't be sure we didn't just regress

I agree. However, no energy to do that right now.

---

Comments from Reviewable

[justin808]

Review status: all files reviewed at latest revision, 12 unresolved discussions.

---

spec/dummy/client/webpack.client.base.config.js, line 63 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

??

yep, duplicate line, fixed

---

spec/dummy/config/initializers/react_on_rails.rb, line 86 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

should this be changed to an array of globs so that we can do *.png and get the files in nested folders?

there's no nested folders -- webpack is all flat, as is the rails process.

---

.rubocop.yml, line 54 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

@samnang This is because I want the config file to take the old or new value of a given property. Just adding the additional config value boosted this. Maybe I should set this override locally in the file, @robwise.

Done.

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

agree with @alleycat-at-git, this is not necessary, webpack automatically modifies references when it fingerprints assets

This has nothing to do with fingerprinting. This just tells rails to publish this directory. 

---

spec/dummy/config/initializers/assets.rb, line 30 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

wait, why is this not reading from our config?

no change any more

---

Comments from Reviewable

[coveralls]

Coverage remained the same at 82.305% when pulling 98e2076 on alleycat-at-git-alexey/replace_symlinks_copy into 20f98d9 on master.

[alexeuler]

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 13 unresolved discussions.

---

lib/tasks/assets.rake, line 27 [r4] (raw file):

        puts "React On Rails: Symlinking #{target_path} to #{symlink_path}"
        `cd #{ReactOnRails::assets_path} && ln -s #{target} #{symlink}`
      end

I think there were problems with this exact line. If we are in a root assets folder (public/assets) and asset in svg/1-fingerprint.svg then what it will do - it will make a symlink in public/assets/svg that will relatively point to svg/1-fingerprint.svg so effectively it will resolve to public/assets/svg/svg/1-fingerprint.svg which is non-existent.

---

Comments from Reviewable

[justin808]

Review status: all files reviewed at latest revision, 13 unresolved discussions.

---

lib/tasks/assets.rake, line 27 [r4] (raw file):

Previously, alleycat-at-git (Alexey) wrote…

I think there were problems with this exact line. If we are in a root assets folder (public/assets) and asset in svg/1-fingerprint.svg then what it will do - it will make a symlink in public/assets/svg that will relatively point to svg/1-fingerprint.svg so effectively it will resolve to public/assets/svg/svg/1-fingerprint.svg which is non-existent.

No problem because no sub dirs are used. I tested this.

---

Comments from Reviewable

[robwise]

We recommend you still have webpack fingerprint these files itself so that you will
still properly bust their respective caches when you change them.

I suspect that would be possible but unlikely. The file-loader does this MD5 name by default.

You suspect that what it does by default would be possible but unlikely?

---

Review status: all files reviewed at latest revision, 13 unresolved discussions.

---

docs/additional-reading/rails-assets.md, line 56 [r3] (raw file):

Rails says what it's doing when compiling assets

Ok makes sense then

There is only one ReactOnRails.trace mode.

but there's trace, and then there's that other env var thing that you can set to YES as well isn't there?

---

lib/tasks/assets.rake, line 114 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

There's no copying. We just add symlinks and delete any broken symlinks. In fact, Rails intentionally does not remove stale assets, as you can have older copy of the page still requesting an older resource.

that comment was from a previous revision when we were still doing the change to copying

---

spec/dummy/config/initializers/react_on_rails.rb, line 86 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

there's no nested folders -- webpack is all flat, as is the rails process.

I talked with @alleycat-at-git, I think the confusion was he wanted to reference Rails-only assets from webpack as well, but I we need to allow for doing that because you wouldn't be busting the cache, you should just place said asset in your `client` dir instead

---

Comments from Reviewable

[robwise]

Review status: all files reviewed at latest revision, 10 unresolved discussions.

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

This has nothing to do with fingerprinting. This just tells rails to publish this directory.

@justin808 I think those comments were out of date, it seems to be fixed now

---

Comments from Reviewable

[alexeuler]

---

Comments from Reviewable

[justin808]

Actually, @robwise is right. https://github.com/webpack/file-loader#filename-templates

HOWEVER, should we just document that we don't support that for now?

And just list that as an issue (and an exercise for the next react_on_rails contributor)?

@alexfedoseev Any opinion?

---

Review status: all files reviewed at latest revision, 10 unresolved discussions.

---

Comments from Reviewable

[justin808]

BTW, I think the problem that @alleycat-at-git ran into in terms of using a file path for an image in JSX could have been solved by following one of the examples here: https://github.com/webpack/file-loader#examples.

Overall, I say we document this design decision and indicate that somebody that wants this can submit a PR to add this enhancement.

---

Review status: all files reviewed at latest revision, 10 unresolved discussions.

---

Comments from Reviewable

[robwise]

HOWEVER, should we just document that we don't support that for now?

It's already automatically supported and is currently being used on F&G in production. Whether or not webpack fingerprints its assets is its own business that it knows how to deal with via the file and url loaders, we just need to make sure Rails doesn't get in the way by fingerprinting them again (or more accurately, that we have symlinks without the rails fingerprint in the filename).

Since we can't rely on Rails's fingerprinting, it's definitely a best practice to have webpack fingerprint assets since that are being referenced by the file/url loaders so that their caches will be properly busted.

---

Review status: all files reviewed at latest revision, 8 unresolved discussions.

---

Comments from Reviewable

[justin808]

@robwise by "that", I mean subdirectories. I'll see if there's an easy fix to allow that.

---

Review status: all files reviewed at latest revision, 8 unresolved discussions.

---

Comments from Reviewable

[justin808]

@robwise @alleycat-at-git Easier to fix the issue than doc it.

[coveralls]

Coverage remained the same at 82.305% when pulling 745914b on alleycat-at-git-alexey/replace_symlinks_copy into 20f98d9 on master.

[justin808]

I moved the rake code to a module.

[justin808]

@samnang @mapreal19 What's the best way to write these tests given the dependencies on the Rails and ReactOnRails config values? I"m thinking of using tmpdir and tempfile, along with some sort of way to set the the global config values temporarily.

And if we make files for test in a tempdir, we don't need to cleanup, right?

[justin808]

Review status: 22 of 27 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

---

spec/dummy/config/initializers/react_on_rails.rb, line 86 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

I talked with @alleycat-at-git, I think the confusion was he wanted to reference Rails-only assets from webpack as well, but I we need to allow for doing that because you wouldn't be busting the cache, you should just place said asset in your client dir instead

You could place the asset in the client dir, and access that from Rails.

@alleycat-at-git @robwise The key is to use the Webpack loader to get the proper file name that has the MD5/hash.

https://github.com/webpack/file-loader#examples

---

Comments from Reviewable

[justin808]

Review status: 22 of 27 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

---

spec/dummy/client/app/assets/fonts/OpenSans-Light.svg, line 1 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

why are we adding 1000 lines of font svg code, we already have svgs we are testing, I would delete this

Done.

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Previously, robwise (Rob Wise) wrote…

@justin808 I think those comments were out of date, it seems to be fixed now

What is fixed now? I believe that Rails always intelligently would only include stuff in files like application.js or refereenced in the sass.

---

spec/dummy/config/initializers/assets.rb, line 30 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

no change any more

Done.

---

Comments from Reviewable

[mapreal19]

Review status: 22 of 27 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

---

spec/react_on_rails/assets_precompile_spec.rb, line 6 [r6] (raw file):

Previously, justin808 (Justin Gordon) wrote…

@samnang @mapreal19 What's the best way to write these tests given the dependencies on the Rails and ReactOnRails config values? I"m thinking of using tmpdir and tempfile, along with some sort of way to set the the global config values temporarily.

And if we make files for test in a tempdir, we don't need to cleanup, right?

Maybe we could stub config values and have different contexts?

Yeah we shouldn't need to cleanup if using tempdir.

FYI this method could be useful http://ruby-doc.org/stdlib-2.0.0/libdoc/tmpdir/rdoc/Dir.html#method-c-mktmpdir

---

Comments from Reviewable

[robwise]

@justin808 oh, according to what Alexey told me that's already supported as well though; you just don't reference it in your JS code with the nesting because the symlinks flatten everything. But it's a bad practice to be putting assets you need for webpack into your rails assets, especially since this means you cannot cache them, so that doesn't make sense to me. Why wouldn't you just put it in your client folder like normal?

A totally different, more likely issue is that someone who has rails assets that have identical filenames but are in different folders, when we symlink to a flat structure, those symlinks will have identical filenames and therefore you will have some type of naming collision. This could be avoided one of two ways:

• only symlink webpack assets
• retain folder structure when symlinking

---

Review status: 22 of 27 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

---

spec/dummy/config/initializers/react_on_rails.rb, line 86 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

You could place the asset in the client dir, and access that from Rails.

@alleycat-at-git @robwise The key is to use the Webpack loader to get the proper file name that has the MD5/hash.

https://github.com/webpack/file-loader#examples

yep, been doing it for 8 months now

---

spec/dummy/config/initializers/assets.rb, line 17 [r2] (raw file):

Dir.glob(Rails.root.join("client", "app", "assets", "**/")).each do |path|
Rails.application.config.assets.paths << path.chop
end

this got taken back out, the comments were on that ^. so it's fixed now

---

Comments from Reviewable

[justin808]

Review status: 22 of 27 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

---

spec/react_on_rails/assets_precompile_spec.rb, line 6 [r6] (raw file):

Previously, mapreal19 (Mario Pérez) wrote…

Maybe we could stub config values and have different contexts?

Yeah we shouldn't need to cleanup if using tempdir.

FYI this method could be useful http://ruby-doc.org/stdlib-2.0.0/libdoc/tmpdir/rdoc/Dir.html#method-c-mktmpdir

@samnang @mapreal19 @robwise @aaronvb @jbhatab @alleycat-at-git

I'm torn over shipping this absolutely needed bug fix without the proper tests, as we want to display best practices. However, I'm beyond swamped right now!

@samnang @mapreal19 any example specs that point to how we could stub out the directories for the Rails and ReactOnRails config values, and then we could create temp files, and then verify that the new methods do the right thing?

---

Comments from Reviewable

[samnang]

Reviewed 1 of 4 files at r6.
Review status: 22 of 27 files reviewed at latest revision, 9 unresolved discussions, some commit checks broke.

---

spec/react_on_rails/assets_precompile_spec.rb, line 6 [r6] (raw file):

Previously, justin808 (Justin Gordon) wrote…

@samnang @mapreal19 @robwise @aaronvb @jbhatab @alleycat-at-git

I'm torn over shipping this absolutely needed bug fix without the proper tests, as we want to display best practices. However, I'm beyond swamped right now!

@samnang @mapreal19 any example specs that point to how we could stub out the directories for the Rails and ReactOnRails config values, and then we could create temp files, and then verify that the new methods do the right thing?

@justin808 When I look at the code, I see file system is really couple to the implementation, so I think the only way we need touch file system api, each we use tmpfile/tmpdir, https://github.com/fakefs/fakefs, or https://github.com/simonc/memfs. Then you can away from coupling with the real file system path. /cc @mapreal19

---

.rubocop.yml, line 54 [r2] (raw file):

Previously, justin808 (Justin Gordon) wrote…

Done.

Not sure, something that should be standard should be in this file. An overrided value that's for personal preference which global doesn't enforce could go in local config that is ignore by your global git ignore.

---

Comments from Reviewable

[coveralls]

Coverage decreased (-4.6%) to 77.749% when pulling fcde037 on alleycat-at-git-alexey/replace_symlinks_copy into e6afa98 on master.

[justin808]

@mapreal19 @samnang last commit should make testings much easier. Agree?

---

Review status: 22 of 27 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

---

Comments from Reviewable

[coveralls]

Coverage decreased (-4.8%) to 77.551% when pulling 1e7ab23 on alleycat-at-git-alexey/replace_symlinks_copy into e6afa98 on master.

[justin808]

I'll be pulling #490 in for the test. Thanks @dzirtusss .

[coveralls]

Coverage decreased (-0.03%) to 82.27% when pulling 48cb445 on alleycat-at-git-alexey/replace_symlinks_copy into e6afa98 on master.

[coveralls]

Coverage decreased (-0.03%) to 82.27% when pulling a6e35fe on alleycat-at-git-alexey/replace_symlinks_copy into cdb246b on master.

[coveralls]

Coverage decreased (-0.03%) to 82.27% when pulling a6e35fe on alleycat-at-git-alexey/replace_symlinks_copy into cdb246b on master.