feat(exclude-files): Exclude files with a !
#188
Conversation
* Refactor `InputFileResolver`, included a new class `PatternResolver` in order to reuse functionality for both `mutate` and `files`. * Ignore patterns starting with an `!` as long as they are provided as strings * Deduplicate files, first occurance wins.
| }); | ||
| } | ||
|
|
||
| function markAdditionalFilesToMutate(allInputFiles: InputFile[], additionalMutateFiles: string[]) { |
There was a problem hiding this comment.
Why are many of these functions outside of a class definition?
There was a problem hiding this comment.
No particular reason. I'll move them back up. Of course they don't need to be part of the class, but keeping them as static methods does keep them nicely in the class definition yes.
| additionalMutateFiles.forEach(mutateFile => { | ||
| if (!allInputFiles.filter(inputFile => inputFile.path === mutateFile).length) { | ||
| errors.push(`Could not find mutate file "${mutateFile}" in list of files.`); | ||
| constructor(descriptor: InputFileDescriptor | string, private previous?: PatternResolver) { |
There was a problem hiding this comment.
Why did you choose an implementation that gave every PatternResolver a link to the previous one? For me, it would make more sense when the InputFileResolver would combine each of the PatternResolvers, while the PatternResolver now does it himself.
There was a problem hiding this comment.
This way we can keep the InputFileResolver clean by moving part of the logic to PatternResolver. It's a more functional approach, right in line with my current experience programming Scala ;).
I can see where you're coming from, do you want me to move it back to the InputFileResolver?
Move global functions to be static methods on the 2 classes.
| return inputFiles; | ||
| }); | ||
| } | ||
|
|
||
| private static validateFileDescriptor(maybeInputFileDescriptors: Array<InputFileDescriptor | string>) { |
There was a problem hiding this comment.
Do we still have to keep all of these methods static? They only seem to be called from inside non-static functions and they're private.
There was a problem hiding this comment.
Yes, but they don't use the this pointer so they can be static. Rather see them as instance functions?
There was a problem hiding this comment.
I moved them to be instance methods. Looks a bit cleaner, i agree.
* Move static methods to be instance methods
|
I'll be so glad when it's 2017 and we can drop Node 0.12 support because it keeps failing our build |
|
Released in 0.5.4 |
|
We should remove the support next week. You know... as a new years gift to ourselves 😁 |
Add a way to exclude files. This works respecting the order of the file patterns. Only works when providing patterns as a
string, not for theInputFileDescriptorformat.InputFileResolver, included a new classPatternResolverin order to reuse functionality for bothmutateandfiles.!as long as they are provided as stringsAs discussed in stryker-api#10