upgrade @types/fuzzaldrin-plus to address API changes

Recently I had to build a similar fuzzy filtering feature like the one that works in many places of Github Desktop. Since this project is open source I decided to take a peak to see how you guys implemented it and what packages you used.

There I noticed that you are passing the options to the fuzzaldrin-plus functions as a fourth parameter:

https://github.com/desktop/desktop/blob/2da984bbff805a1647c467453b766a8c58939aa9/app/src/lib/fuzzy-find.ts#L11-L13

https://github.com/desktop/desktop/blob/2da984bbff805a1647c467453b766a8c58939aa9/app/src/lib/fuzzy-find.ts#L40-L42

The documentation of that package is kind-of lacking to say the least, so if you check source code for version 0.6.0 you will notice that the options should be the third parameter instead, so right now the options object in Desktop’s implementation is being completely ignored and using the defaults! :

https://github.com/jeancroy/fuzz-aldrin-plus/blob/84eac1d73bacbbd11978e6960f4aa89f8396c540/src/fuzzaldrin.coffee#L17-L20

  score: (string, query, options = {}) ->
    return 0 unless string?.length and query?.length
    options = parseOptions(options, query)
    if options.usePathScoring

Also, the option isPath: boolean doesn’t exist in that version, so I assume you meant usePathScoring. These are the default options the package has…

https://github.com/jeancroy/fuzz-aldrin-plus/blob/84eac1d73bacbbd11978e6960f4aa89f8396c540/src/fuzzaldrin.coffee#L41-L49

#Setup default values
parseOptions = (options, query) ->

  options.allowErrors ?= false
  options.usePathScoring ?= true
  options.useExtensionBonus ?= false
  options.pathSeparator ?= defaultPathSeparator
  options.optCharRegEx ?= null
  options.wrap ?= null

I debugged Desktop locally just to make sure, and indeed this is the case:

If you do decide to make the fix and apply the options, I would suggest that you test it properly since the options that you are setting will impact the behavior of the algorithm and produce different results than the ones you’ve been seeing so far. allowErrors for instance, will indeed allow errors and some mismatchs will happen. Also, the pathSeparator being used so far was either / or \\, so I assume that changing it to ‘-’ will have an impact as well. I wonder why you went with these options ?

/cc @damaneice @j-f1

[reyronald]

@shiftkey By the way, those behavior changes should’ve been caught by some automated tests somewhere. If none of your tests broke after doing those changes, this would be a good opportunity to add them!

[reyronald]

@shiftkey The issues you are seeing are caused because the options object is mutated inside each of the functions that fuzzaldrin-plus exposes by filling out the properties that were not provided. One of the possible options is a preparedQuery which is used instead of the str when it is present. Although you didn’t provide it, it is added to the options variable and then remains there for all the following calls after the first one.

In the mean time, so that you can test out the options, you can mitigate this by destructuring the options object in each call so that a clone is created and the original one it is not mutated.

diff --git a/app/src/lib/fuzzy-find.ts b/app/src/lib/fuzzy-find.ts
index 7ade1dfc6..eb775c1bc 100644
--- a/app/src/lib/fuzzy-find.ts
+++ b/app/src/lib/fuzzy-find.ts
@@ -9,7 +9,7 @@ const options: fuzzAldrin.IFilterOptions = {
 }
 
 function score(str: string, query: string, maxScore: number) {
-  return fuzzAldrin.score(str, query, undefined, options) / maxScore
+  return fuzzAldrin.score(str, query, { ...options }) / maxScore
 }
 
 export interface IMatches {
@@ -38,7 +38,7 @@ export function match<T, _K extends keyof T>(
       const matches: Array<ReadonlyArray<number>> = []
       const itemTextArray = getKey(item)
       itemTextArray.forEach(text => {
-        matches.push(fuzzAldrin.match(text, query, undefined, options))
+        matches.push(fuzzAldrin.match(text, query, { ...options }))
       })
 
       return {