Make src_paths behave as expected when using --resolve-all-configs and improve performance #2142
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using
--resolve-all-configs
, there is unexpected behavior in thatsrc_paths
ends up resolving relative to the project root, which defaults to the current working directory. This results in first-party modules being marked as third-party modules in the default case.Under the previous implementation, one possible workaround would be to specify the relative path to config directory (e.g.
relative/path/to/configdir/src
). However, assuming that the most common use of--resolve-all-configs
is to support multiple sub-projects in the same repository/overall directory, this workaround would now require each sub-project to understand where it lives in the filesystem.This change proposes a fix that sets
directory
on theconfig_data
to be the directory containing the used configuration file if not already set. Downstream, this directory is then used to resolve the absolute paths specified bysrc_paths
.This change also introduces performance improvements to
find_all_configs
by pruning as we walk the filesystem and other smaller performance enhancements.Fixes #2045