Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed path matching with reek config #23

Merged
merged 1 commit into from
Sep 19, 2019

Conversation

paul
Copy link
Contributor

@paul paul commented Aug 28, 2019

Awhile back, I fixed reek to be able to know the filename being examined, even if it wasn't passed a File object: troessner/reek#1343

When the reek config file has different configuration for different files/directories, this allows reek to match the filenames when not using the reek CLI.

However, it wasn't working to match the full path as provided by pronto-reek. For example, if your reek.yml specifies "lib/foo.rb", pronto-reek was supplying files as
Pathname("/home/me/code/project/lib/foo.rb")`, and it was failing to match.

This change modifies the new_file_full_path from the patch to instead be a relative path from the pwd, which is correctly matched by the reek config.

Caveats:

  • Testing this might be pretty complicated, we'd need a double that knows a whole lot about Reek internals to generate a config.
  • Pronto::Git::Patch doesn't expose an easy way to get a relative path. I had to do the relative_path_from work twice in Pronto::Reek#run, this could be simpler if Pronto::Git::Patch exposed a #new_file_relative_path method.
  • I had originally wanted to do patch.new_file_full_path.relative_path_from(Pathname.new(repo.path)), but this did not work in the tests because the fixture git repo is in a subdir, so reek was unable to open "./hello.rb". While relative_path_from repo.path worked fine testing this against my own repository, I'm not familiar enough with how pronto treats submodules or nested git directories to know if that approach will work. I also don't know if pwd is the right approach either, depending on how reek/pronto is called. Probably a better thing to do is try and figure out the directory containing a reek config file, and do everything relative from there.

Fixes #19

Awhile back, I fixed reek to be able to know the filename being
examined, even if it wasn't passed a File object:
troessner/reek#1343

When the reek config file has different configuration for different
files/directories, this allows reek to match the filenames when not
using the reek CLI.

However, it wasn't working to match the full path as provided by
pronto-reek. For example, if your reek.yml specifies "lib/foo.rb",
pronto-reek was supplying files as
`Pathname("/home/me/code/project/lib/foo.rb")`, and it was failing to
match.

This change modifies the new_file_full_path from the patch to instead be
a relative path from the pwd, which is correctly matched by the reek
config.

Caveats:

 * Testing this might be pretty complicated, we'd need a `double` that
   knows a whole lot about Reek internals to generate a config.
 * Pronto::Git::Patch doesn't expose an easy way to get a relative
   path. I had to do the relative_path_from work twice in
   Pronto::Reek#run, this could be simpler if Pronto::Git::Patch exposed
   a `#new_file_relative_path` method.
 * I had originally wanted to do
   `patch.new_file_full_path.relative_path_from(Pathname.new(repo.path))`,
   but this did not work in the tests because the fixture git repo is in
   a subdir, so reek was unable to open "./hello.rb". While
   relative_path_from repo.path worked fine testing this against my own
   repository, I'm not familiar enough with how pronto treats submodules
   or nested git directories to know if that approach will work. I also
   don't know if `pwd` is the right approach either, depending on how
   reek/pronto is called. Probably a better thing to do is try and
   figure out the directory containing a reek config file, and do
   everything relative from there.
@mkrawc
Copy link

mkrawc commented Sep 3, 2019

As far as I can see this can also fix an issue with pronto-reek ignoring reek directories configuration directive that I've came accross recently. It would be great to get it merged quickly.

@doomspork
Copy link
Member

@paul and @mkrawc sorry for the delays, I'm recovering from a pretty serious back injury and it's really limited my ability to get in front of the computer unfortunately.

@doomspork doomspork merged commit 83dedb5 into prontolabs:master Sep 19, 2019
@paul paul deleted the bugfix/fix-reek-path-matching branch September 19, 2019 23:14
@paul
Copy link
Contributor Author

paul commented Sep 19, 2019

Thanks @doomspork. Hope you start feeling better soon!

@ibrahima
Copy link

Hi! Is it possible to cut a release that has this fix merged? This issue has been causing Reek to be overactive on our PRs for a while, but we've just been ignoring it. We can also just install from master but if it's not too much trouble a new release would be wonderful. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pronto-reek comments on files that are in exclude_paths
4 participants