[Bug] `filter` + `options()` double-filtering issue for autocomplete

[LangLangBart]

Environment

• OS: macOS
• Node: 25.8.1
• Package: @clack/prompts
• Package Version: 1.1.0

Describe the bug

When options is a function, clack internally calls it to get the candidate
list, then still runs its own filter function over that result. This means any
pre-filtered / pre-sorted list returned by options() gets filtered a second
time by clack's default substring matcher — silently dropping items that a
custom algorithm (e.g. fuzzysort) considered valid matches.

So the user is forced to include filter: () => true to workaround this ergonomic pitfall.

To Reproduce

https://stackblitz.com/edit/node-ynqghq1u?file=index.js

Steps to reproduce the behavior:

run the stackblitz script with: node index.js

Notice: ❌ nothing is being listed

❯ node index.js
│
◆  Select a package
│
│  Search: vte█ (0 matches)
│  No matches found
│  ↑/↓ to select • Enter: confirm • Type: to search

repeat with node index.js --filter

Notice: ✅ correct list with vite at the top

❯ node index.js --filter
│
◆  Select a package
│
│  Search: vte█
│  ○ vite
│  ○ vitest
│  ● vitepress
│  ↑/↓ to select • Enter: confirm • Type: to search

Expected behavior

When options is a function (i.e. the caller manages filtering), clack should
not apply an additional filter pass on the returned list.

Additional Information

You may say 'why dont u use fuzzysort in the filter?'

If I did that, I’d lose the ranking: vite would move from first to last.

filter(search, option) {
  if (!search) {
    return true
  }
return fuzzysort.go(search, [option.value]).length > 0
},
options: packages.map(name => ({ label: name, value: name }))

❯ node index.js
│
◆  Select a package
│
│  Search: vte█ (3 matches)
│  ● vitepress
│  ○ vitest
│  ○ vite

Related Prs:

• feat(core + prompts): adds autocomplete #288
  • Introduced autocomplete. filter always runs over options() result
• feat(prompts): add custom filter option to autocomplete #444
  • Exposed filter as a option

---

PS: The point of this issue report is that I found it counterintuitive to
include filter: () => true as a workaround for this issue. I hope you agree or
can provide a documentation example so that more people won’t encounter this
pitfall.

[dreyfus92]

hey @LangLangBart thank you for spotting this, agreed this is a bug. when options is a func we should use the returned list as is and not run the filter. we'll fix that and add a test + a doc note so the behavior is clear 😄

[LangLangBart]

Expected behavior
When options is a function (i.e. the caller manages filtering), clack should not apply an additional filter pass on the returned list.

Another option is to let users disable (filter: false) with a boolean flag, preventing unnecessary filtering.

My expected behavior fits my use case, but other users may still want clack to handle filtering even when options is a function.

@43081j gave some more insight in its review comment: #489 (comment)

If users want a custom filter while preserving ranking, they must set options as a function and signal to disable the default filter. An example in the docs would help, as many users likely want to keep ranking when using a custom fuzzy sort filter.

[43081j]

If users want a custom filter while preserving ranking, they must set options as a function and signal to disable the default filter

if the PR lands, this isn't true anymore, right?

setting an options function removes the default filter.

i think we're all good now and if the PR lands we can close this

[LangLangBart]

Agreed that once the PR lands, this issue can be closed!