Hi there, thanks for this very useful gem!
I've been trying to use leftovers to find unused code within a specific part of my Rails application (app/models), but I've run into a limitation with how the file paths are configured.
The Problem
Currently, the include_paths and exclude_paths configurations define the scope for two distinct operations simultaneously:
- Discovering definitions (methods, constants, etc.) that should be checked.
- Scanning for usages (calls) of those definitions.
This makes it impossible to check for unused definitions in a narrow scope (e.g., just my models) while searching for usages across a much wider scope (e.g., the entire application).
Use Case
My goal is to identify and remove unused methods and constants that are defined exclusively within a certain directory (e.g. app/models).
To do this, leftovers needs to scan my entire project for usages (in controllers, workers, views, etc.). However, when I configure leftovers to do a full-project scan, the report includes unused items from every part of the codebase, which is overwhelming.
Conversely, if I try to limit the scope like this:
# .leftovers.yml
include_paths:
- 'app/models/**/*.rb'
leftovers will incorrectly flag a model method as "unused" if (for example) its only call site is in a controller, because the controller files are not part of the include_paths scope where leftovers is looking for usages.
Proposed Solution
It would be incredibly helpful to be able to configure these two scopes separately. I propose introducing a new configuration key, perhaps definition_paths.
This new key would tell leftovers: "Only report unused items that are defined in these files."
The existing include_paths and exclude_paths would then be used to define the (much larger) scope for where to find usages of those definitions.
A configuration for my use case might look like this:
# .leftovers.yml
# Only report unused code that is DEFINED in these files.
definition_paths:
- 'app/models/**/*.rb'
# But look for USAGES of that code across the entire project.
include_paths:
- '**/*.rb'
exclude_paths:
- node_modules/**/*
- vendor/**/*
This would provide a much more powerful and targeted way to use leftovers on large, mature codebases where a full-project analysis can be too noisy to start with.
Thanks for your consideration
Hi there, thanks for this very useful gem!
I've been trying to use leftovers to find unused code within a specific part of my Rails application (app/models), but I've run into a limitation with how the file paths are configured.
The Problem
Currently, the include_paths and exclude_paths configurations define the scope for two distinct operations simultaneously:
This makes it impossible to check for unused definitions in a narrow scope (e.g., just my models) while searching for usages across a much wider scope (e.g., the entire application).
Use Case
My goal is to identify and remove unused methods and constants that are defined exclusively within a certain directory (e.g.
app/models).To do this, leftovers needs to scan my entire project for usages (in controllers, workers, views, etc.). However, when I configure leftovers to do a full-project scan, the report includes unused items from every part of the codebase, which is overwhelming.
Conversely, if I try to limit the scope like this:
leftovers will incorrectly flag a model method as "unused" if (for example) its only call site is in a controller, because the controller files are not part of the
include_pathsscope where leftovers is looking for usages.Proposed Solution
It would be incredibly helpful to be able to configure these two scopes separately. I propose introducing a new configuration key, perhaps
definition_paths.This new key would tell leftovers: "Only report unused items that are defined in these files."
The existing
include_pathsandexclude_pathswould then be used to define the (much larger) scope for where to find usages of those definitions.A configuration for my use case might look like this:
This would provide a much more powerful and targeted way to use leftovers on large, mature codebases where a full-project analysis can be too noisy to start with.
Thanks for your consideration