если только файл с компонентом не назван component.ts )

тогда в шаблоне черт ногу сломит)

filters: [
       {
         name: 'project_ids',
         type: ItemType.Select,
         label: 'Projects',
         multiple: true,
         values: () => {
           return this._projectService.gets({ partner_id: this.partner.id })
             .pipe(
               map((response) => response.map((project) => {
                 return { value: project.id, name: ${project.code ? project.code : ''} ${project.name} }
               }))
             )
         }
       },

Вот это отлично спрячется в компонент с конкретным фильтром

это довольно трудно будет поддерживать.

тогда в шаблоне черт ногу сломит)

filters: [
       {
         name: 'project_ids',
         type: ItemType.Select,
         label: 'Projects',
         multiple: true,
         values: () => {
           return this._projectService.gets({ partner_id: this.partner.id })
             .pipe(
               map((response) => response.map((project) => {
                 return { value: project.id, name: ${project.code ? project.code : ''} ${project.name} }
               }))
             )
         }
       },

Труднее, чем сейчас?

в таком случае я бы сделал динамические фильтры и вынес их в провайдеры

В целом вариант, но здесь любят вклиниваться в функцию values или еще куда-нибудь в зависимости от вью

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

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

в случае переиспользования есть factory которые могут в одном модуле давать разные конфиги

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

в случае с декомпозицией как бы ты хранил это все? А точнее где, с учетом модульности, и lazy для этих модулей. Просто в одном статическом модуле?

В случае с Ivy все довольно легко разрешается с lazy modules.
А так да, для начала одного статичного модуля будет достаточно.
Тут главное заложить принцип, а остальное уже разрулится.

а что ты имеешь ввиду с Ivy? То что он будет грамотно модули бить?