Зависимость глубокое погружение / аудит / анализ происхождения / обзор импорта пакета Webpack Bundle для проекта TypeScript & React

Question

Откуда я иду...

Я новичок в этом проекте, и глубокое погружение заняло бы значительное время. Я новичок в TypeScript и не имею глубокого понимания WebPack.

Что мы имеем

В проекте с несколькими рабочими пространствами пряжи у нас есть разумно настроенный пакет Webpack. Но мы пытаемся сократить долю нашего поставщика с разделением кода с 2,98 до... чего-то меньшего.

Что было опробовано:

• webpack-bundle-analyzer оказать полезное графическое представление того, что находится в комплекте.
• webpack-visualizer-plugin сделать красивый диск, который аналогичным образом показывает, что находится в комплекте, пропорционально.
• yarn list | grep ^├ | wc -l кажется, не делает то, что мне нужно. Я считаю, что существует пара тысяч "зависимостей" верхнего уровня. К сожалению, это во всех рабочих пространствах.
• yarn why core-js - кроме расплывчатой ​​иерархии, не дает достаточно подробностей, чтобы я мог определить, "почему" он включен. Это не похоже на ссылки на пакеты Webpack.

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

Цели

Уменьшите размер связки с помощью более ограничительных включений, где это возможно

Уменьшите размер упаковки, удалив дубликаты включений.
По крайней мере, я бы хотел лучше понять, как дедуплицировать rxjs, webpack-bundle-analyzer, увеличенный в rxjs

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

Детальный анализ включения

Я надеюсь найти инструмент, который может "объяснить" (показать / проиллюстрировать / список), почему включена зависимость (файл / библиотека / пакет), с верхнего уровня вниз. Например, rxjs - это включения в этот файл и строку, которые включены в этот файл и строку... пока мы не достигнем верхнего уровня.

core-js
  +- polyfill @ line#
     +- babel @ line#
       +- myPackage/file @ line#
         +- mySourceFile @ line#

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