-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Avoid overly-broad tasklib.find call #3249
Conversation
want to have @ericsciple take a look? |
// include the wildcard character because: | ||
// dirname(c:\foo\bar\) => c:\foo (which will make find() return a bunch of stuff we know we'll discard) | ||
// dirname(c:\foo\bar\*) => c:\foo\bar | ||
let findPathRoot = path.dirname(pattern.slice(0, idx + 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fyi a find match function was added in newer version of the lib. the firstWildcardIndex
isn't entirely accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eventually we want to get to a consistent experience across in the box tasks: https://github.com/Microsoft/vsts-task-lib/blob/master/node/docs/findingfiles.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't fix. I strongly agree that we should converge on a single file finding experience, but changing matchers is a breaking change, and I'm not interested in changing the observable behavior in this PR.
The scope of this PR is simply to stop enumerating the parent of the directory we're matching against with our existing matcher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes i agree it is something outside the scope of this pr
the change here seems appropriate
note, even with most of the glob options turned off, it's character sets that are not accounted for by firstWildcardIndex and cannot be turned off
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want consistency, your team should be opinionated and remove almost all of the options from that interface. Consistent UI will just be even more confusing if each task selects different options underneath.
There should also be structures in the task definition to make writing the UX consistently be easier than not doing so.
We haven't gotten complaints about character sets not working right, and I don't think we've documented anything but *, ** and ?, so I think we'll just leave that to reaction if someone complains
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for globbing consistency, the strategy is: 1) task author guidance (doc linked above). 2) good defaults for the glob options. changing the defaults for the glob functions was a breaking change in the 2x task lib. 3) update in the box tasks. they are open source examples.
for the UX structures, what do you have in mind? this is straying far from the PR :) you might want to shoot a mail to bryan or chris
No description provided.