Есть подозрение, что этот агрегационный счётчик не нужен, так как конкретно для задачи динамического поиска он будет всегда выдавать число, равное числу матчей в файле, т.к. паттерны для поиска в случае динамического поиска не повторяются!

Желательно протестировать через динамический поиск и затем выпилить

Если наискать побольше результатов поиска, а затем немножечко поколлапсить, нажимая на стрелочку вниз (слева от названий файлов) в результирующей таблице, то можно заметить, что строгая череда сменяющегося бэкграунда на каждой строке сбивается, иногда подряд идут несколько строк одного цвета.
Реализовано так из-за двух одновременных решений:

• поочерёдная подсветка строк работает с помощью css селектора tr:nth-child(2n)
• коллапсинг реализован через display: none

Конечно же tr:nth-child(2n) не учитывает, что на скрытые элементы наложен display: none и поэтому такой баг присутствует.
Как решение можно попытаться скрывать элементы другим способом, или же сделать стили подсветки иначе

последний аргумент ripgrep это paths, то есть потенциально несколько путей, например:
можно запустить поиск как в одном пути, например rg "pattern" somePath/
или в нескольких: rg "pattern" somePath/ anotherPath/
В команде combined-search или cs так сделать нельзя, т.к. последним аргументом передаётся всего один путь
Нужно добавить возможность искать в множестве путей

Если сделать запрос с игноркейсом, например cs -i "new", то найденные матчи не будут выделены жирненьким, а должны ведь.
Как нормально работающий кейс, можно ввести запрос без -i опции, например cs "new"
Надо сделать, чтобы в сценарии с игноркейсом тоже выделялось

openEditorService.js служит для того, чтобы нажимая на результат поиска, мы видели открывающийся редактор кода на указанном месте. (если уже запущен webpack-dev-server, то он уже юзает этот функционал и openEditorService.js запускать не надо)
Cейчас его можно запускать только так node openEditorService.js
Нужно сделать его запускающимся наподобии самого поиска, как combined-search или cs, то есть combined-search-oes или например cs-oes

Нужно написать документацию :)

Комплексная фича, сначала стоит обсудить план как её делать.
Пока пришло в голову два варика:

• использовать готовый инструмент для этого
• или же делать краткое summary по директориям и файлам в них, а затем искать по summary рипгрепом, так же как и в обычном поиске