Be able to run rubocop in a "nested project" without picking up config in parent directories. #11011
Comments
|
A similar discussion about running rubocop both from a root project and from nested projects happened in #4328, the suggested technique would be to either:
I think that will support your use-case. However, I'm also afraid that you may run into surprising issues when running |
|
Thanks for response @tdeo it led me to the right answer, but it still feels like a workaround.
However if I do The problem is that the scan for the parent So this works -- but feels like a workaround I tried using https://github.com/timdiggins/rubocop-nested-test: output (with --debug flag) |
|
That's indeed surprising, the implementation of the logic for finding the project root (which is the place up to where rubocop includes configuration recursively), as being the parent-most directory containing a The commit setting that behavior is e1a2da0e28, but unfortunately lacks a bit of context about the reason behind the change (except excluding the current_user's home directory). My first thought would rather be that rubocop should consider as project root the first ancestor of Maybe @bbatsov can give more context about the original choice and his vision of the topic |
|
I have a I think it should not inherit Ideally, though, I'd like to disable inheriting from the global config (actually, expect it to be off by default). Because my personal configuration may or may not make sense for a particular project. |
|
I just ran into this behavior myself. We have a separate project in a subfolder that has its own rubocop configuration and the parent folder has a required rubocop gem we don't want in the subfolder (the gem has no requirement). I think at the minimum I'd really like the ability to control this behavior in the .rubocop.yml itself so I don't need to manage the different places that might be invoking rubocop, including the vs code extension, with the command line argument Does this seem like a reasonable approach? I don't mind getting a PR together, just want to make sure the approach makes sense to you folks before getting started. |
|
I've run into this too. I have a gem I'm working on inside a rails app directory for ease of development with the plan to extract it later. Nothing I have tried will stop rubocop from trying to include the rails app's Rubocop automatically including other additional configuration files outside of the working directory (when one already exists there) is extremely unintuitive, and being unable to stop it from doing so is frankly very irritating. |
|
Another workaround that's worked for me if you typically call require "rubocop/rake_task"
+ require "rubocop/config_finder"
+
+ RuboCop::ConfigFinder.project_root = File.expand_path(".")
RuboCop::RakeTask.newSolves it for |
rubocop ./spec -c /dev/null |
I'm not 100% sure if this is a feature request or a bug report (see below). But here's the issue:
I have a project where I'm trying to add rubocop to a nested project (which is a dependency of the other project but can be run independently - they might be better set up as siblings, but for various reasons the "parent" project is in the parent directory). The rubocop in the nested project adds the configuration of the parent directory, including the "require" - but these are not present in the nested project.
I can exclude the nested project from the parent's rubocop (or include it -- either way are fine and controllable) however there's no way to say to rubocop - run it in this directory and don't reference the parent directory's .rubocp.yml.
Feature request or bug?
As was stated in #9879 :
However #8314 seems to imply there is a concept of project root (and in fact that it shouldn't look in parent directories for
.rubocop.yml)I've used the sections from both feature request and bug report to cover all the bases 😀
Describe the solution you'd like
I think rubocop should have some way of differentiating between traversing down to pick up new configs from a directory (which might well be its own project - it's up to the parent to sensibly include or exclude those directories) and traversing up to look for parent project's config.
When you invoke rubocop in a directory that has a
.rubocop.ymland that is recognised as a project root (by the same tokens that bundler does as per #8314There's would then be a difference between
rubocop nested-projectandExpected behavior
I've documented a toy example in https://github.com/timdiggins/rubocop-nested-test
The top level directory has a
.rubocop.ymland excludes the nested-project.It requires 'rspec-performance', and the Gemfile specifies it also.
When you run
rubocopin the top directory it works as expected.The nested-project directory represents a project nested within the top level project (see below for why it might occur).
The nested-project's
.rubocop.ymldoes not require 'rspec-performance', and the Gemfile does not specify it.Expectation:
cd nested-project; rubocopwould run without error, using just the configuration from the nested-project/.rubocop.ymlActual behavior
if you run
rubocopin the nested-project directory, it fails because rspec-performance gem can't be found.output of `bundle exec rubocop --debug` from nested-project
Steps to reproduce the problem
see above or see https://github.com/timdiggins/rubocop-nested-test
RuboCop version
Workarounds:
The main workaround is to run rubocop only from the parent project, and allow the nested-project to define a .rubocop.yml overriding config as and when appropriate, and never running rubocop when in the nested-project(and probably excluding rubocop from the nested-project's Gemfile).
The text was updated successfully, but these errors were encountered: