Я в свое время mdi-norm сделал, там гибридный подход, иконки - каждая в своем файле, но svg код шарится между иконками как частями (в виде общих импортируемых кусков svg кода), так и полностью, если иконки из разных тем дублируют друг друга.

В итоге чем больше иконок в проекте используется, тем больше экономия за счет общих фрагментов svg-кода и меньше размер бандла.

Чтобы сборщик выкинул неиспользуемые их важно объявить с /*#__PURE__*/ аннотацией, но лучше использовать только те прямые импорты иконок, которые реально есть в проекте. А чтобы вручную постоянно не писать импорты к каждой иконке придумали babel-macrosы

есть пример макроса?

Вся прелесть в том, что ты просто расставляешь теги иконок где угодно по коду 12 разными синтаксическими сахарами (кому как нравится), а сборщик превращает это в svg и подтягивает импорты + максмально дедуплицированный svg код получается.

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

не очень понимаю профит =) в чем разница от явного импорта компонента иконки, я с mui не работал. Сборщик типа вебпака и так их дедуплицирует и поставит каждую использованную по 1 разу в бандл

этот макрос как я понял фиксит проблемы конкретно mui и не является коммон решением для иконок

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

что заключается в синхронизации вручную импортов каждой иконки?

я просто не очень понимаю, какая разница вспомнить название иконки и написать ее импорт, или вспомнить название иконки и написать с ней макро

Этот проект вообще никак с mui не связан :)
Я его написал, чтобы можно было в коде написать ihand и в итоге сборщик сам подтянет импорты, только нужный svg код и он будет гарантировано минимальным и без дубликатов.

А потом я поменяю на i'phone' и снова все импорты сами подтянуться при сборке

Вставить импорт потом идти по коду где иконка используется, поддерживать только нужные импорты, не гарантировано отсутствие дубликатов свг и т.д.

Тогда мне непонятно чем это отличается  от react-svg-loader какого-нибудь с пайплайном с svgo и еще подобной мишурой.

поддержку только нужных импортов обеспечивает no-unused-** правила линтера

Хорошо бы, чтобы я мог в коде просто написать имя иконки тут, имя иконки там, сям, прямо в верстке, а дальше сборщик и библиотека сами: подтянули импорты относящиеся к этой иконке, вставили вместо имени рабочий svg код, чтобы одинаковые по виду иконки шарили общий svg-код, чтобы даже если небольшие куски иконок одинаковые (а иконки часто почти похожи) они тоже даже на уровне фрагментов path g шарили код, ну и чтобы у меня был минимально возможный размер бандла. Вот все это решает mdi-norm :)

Ну из всего перечисленного уникальным является только шаринг кода на уровне фрагментов, но я хз насколько это применимо и профитно в реальности, думаю сильно зависит от проекта.

Остальное бонусы весьма сомнительны, автоимпорты и мапинг по именам. Имена сотни иконок все равно не запомнить и нужен атлас, а атлас можно сделать удобным настолько чтобы он сразу давал импорт нужной иконки в буфер по клику.

я бы потрогал только функционал дедупликации и посмотрел насколько он сокращает бандл, насколько быстро работает и работает ли без косяков. У меня есть целые чанки челиком из иконок и там могут быть повторяющиеся иконки.