You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.
For many configs, files patterns are likely to have an extension on the end (some form of **/*.xx or path/to/**/*.xx) in most cases.
As part of normalize, we could pre-process all the files patterns and identity the set of extensions that any file that could match must have. This could then provide a fast-path out of getConfig() by quickly eliminating any files that don't have an extension matching the known set of extensions. It could even be exposed publicly as part of the API so that they could be used to directly guide file enumeration by consumers.
There are obviously a few cases that would need to turn this fast-path off, such as functions in files, or a * pattern without an extension, but I would hope in a large number of cases (at least once flat config is more widely adopted) that this optimization would be enabled.
The same could be done for ignores, except that functions would no longer disable the optimization (since they can only ignore more files, they can't un-ignore), but care would need to be taken around negated ignore patterns.
I haven't worked out all the semantics of this yet or all the potential corner cases, but it'd be good to get your thoughts on whether it's worth it flesh this out further.
The text was updated successfully, but these errors were encountered:
Interesting idea, but if I'm understanding correctly, it seems like the only real benefit would be when a filename that would not be matched is passed in? So if "foo.txt" is passed in and there are no patterns matching *.txt then it would exit without doing any matching?
If that's correct, then I'm not sure it's worth pursuing. The chances that the config array will be passed a filename that doesn't match any patterns is pretty slim, so we'd be optimizing a cold code path.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For many configs,
files
patterns are likely to have an extension on the end (some form of**/*.xx
orpath/to/**/*.xx
) in most cases.As part of
normalize
, we could pre-process all thefiles
patterns and identity the set of extensions that any file that could match must have. This could then provide a fast-path out ofgetConfig()
by quickly eliminating any files that don't have an extension matching the known set of extensions. It could even be exposed publicly as part of the API so that they could be used to directly guide file enumeration by consumers.There are obviously a few cases that would need to turn this fast-path off, such as functions in
files
, or a*
pattern without an extension, but I would hope in a large number of cases (at least once flat config is more widely adopted) that this optimization would be enabled.The same could be done for
ignores
, except that functions would no longer disable the optimization (since they can only ignore more files, they can't un-ignore), but care would need to be taken around negated ignore patterns.I haven't worked out all the semantics of this yet or all the potential corner cases, but it'd be good to get your thoughts on whether it's worth it flesh this out further.
The text was updated successfully, but these errors were encountered: