Отключить встряхивание дерева в Webpack 4

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

мы недавно перешли с lodash до lodash-es поддержка трясти дерево. Он отлично работает, и пакеты намного меньше, но теперь наша сборка занимает примерно в два раза больше времени (от 3 минут до 6 минут).

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

Я нашел этот недокументированный параметр конфигурации, но я не уверен как это будет применяться https://github.com/webpack/webpack/blob/master/lib/WebpackOptionsDefaulter.js#L207. Очевидно, UglifyJS не работает в dev, поэтому я предполагаю, что все замедление происходит от Webpack, выполняющего работу, чтобы отметить, какие модули не используются.

Я думал, вы могли бы сделать что-то вроде сглаживания lodash-es to lodash только на dev, но это супер hacky, и в любом случае Lodash не работает с import * as _ синтаксис lodash-es требует для дерева тряска

Я предполагаю, что это плагин, который выполняет работу по маркировке импорта как неиспользуемого, но поскольку он включен по умолчанию, я не знаю, как отключить его или удалить из массива плагиновhttps://github.com/webpack/webpack/blob/next/lib/optimize/SideEffectsFlagPlugin.js#L1

странно, что вы не можете просто установить treeShaking: false или что-то в конфиге. https://webpack.js.org/guides/tree-shaking/ не говоря уже о что угодно.

мы уже установка mode to development или production на основе среды сборки, но мы видим эти более медленные времена сборки даже при разработке. это предполагает, что mode: development не отключает обнаружение неиспользуемого модуля.

6
webpack

2 ответов

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

добавить

{
    test: () => !env.production,
    sideEffects: true,
},

на module.rules массив. Это правило будет соответствовать каждому файлу при работе в режиме dev, и никаких файлов при работе в режиме prod. Когда он соответствует файлу, он сообщает Webpack (ложно), что файл имеет побочные эффекты и поэтому не может быть потрясен деревом.

это вернуло наше время сборки с 6 минут до 3 минут на dev.

вряд ли идеально, но при отсутствии правильного варианта конфигурации из Webpack это придется сделать.

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

0

Итак, мой другой ответ помогает, Но не намного. Хотя это позволяет избежать встряхивания дерева, это просто заставляет сборку встроить полную копию lodash в каждый пакет. Для такой кодовой базы, как наша со 100 точками входа, это все еще очень неэффективно. Это сделало сборку быстрее, чем 6 минут, но не где рядом с оригинальными 3 минутами.

Я конец я использовал externals условно игнорировать импорт Lodash полностью, только в dev. Это можно сделать. как

    externals: {
        ...(isProduction ? {} : { 'lodash-es': '_' }),
    },

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

Так что это не совсем общий ответ на этот вопрос – более конкретный для нашего случая использования Lodash и очень большой кодовой базы. Для других кодовых баз или зависимостей отключение встряхивания дерева может быть правильным ответом.

0