Почему не работает Tree Shaking и как с этим жить

[D1k1y]

Вроде facebook flow позволяет делать более гранулированный tree-shaking с помощью flow-графа даже на нетипизированном javascript. https://youtu.be/VEaDsKyDxkY?t=1535

[grigoryvp]

Это теоретическая возможность или его уже с каким-нить бандлером вроде вебпака успели подружить? По видео товарищь вроде как про «возможности» рассказывает. Но что насчет практики?

[3axap4eHko]

уже давно используем flow в продакшн вместе с webpack. существует preset для babel который можно использовать со всем, что поддерживает babel

[3axap4eHko]

но это ведь впоне логично не импортировать целый модуль lodash а отдельный файл(подмодуль) к тому же в es6 большая часть функционала lodash присутствует из коробки вместо ´_.has´ можно писать ´[].includes´ для массивов или ´a in b´ для объектов

[kana-desu]

Есть плагин для babel, который преобразует

import _ from 'lodash';
import { add } from 'lodash/fp';

const addOne = add(1);
_.map([1, 2, 3], addOne);

в

import _add from 'lodash/fp/add';
import _map from 'lodash/map';

const addOne = _add(1);
_map([1, 2, 3], addOne);

Вроде как можно настроить не только для lodash, если аналогичные плагины для ramda (бандл заметно уменьшается).

Когда тришейкинг начнет работать, можно будет просто убрать этот плагин, не меняя код.

Ссылка — https://github.com/lodash/babel-plugin-lodash

[sigeyi]

Вот https://github.com/lodash/babel-plugin-lodash

И можно импортить через _

[Jermes]

даже один метод из lodash дает на выходе бандл размером в полмегабайта

Забандленный lodash+axios и пропущенный через UglifyJsPlugin у меня занимает 93.2KB

[Nikelandjelo]

В тоже время есть Closure Compiler уже как много лет умеет не только трясти деревья но и делать гораздо более сложные оптимизации. Да, требуется использовать типизировать свой код, чтобы достичь наилучшего результата. А если вы уже используете Typescript то стоит посмотрить на https://github.com/angular/tsickle который как раз траспилирует typesecript в js оставляя типы, чтобы потом Closure Compiler всё это заоптимизировал.

[some_x]

Если у вас такие ограничения по памяти, то зачем вы вообще пишите на javascript?
не проще ли на c++?

[ACPrikh]

Вы, батенька, мешаете играть в любимые игрушки! Если уж говорить о выборе инструмента, соответствующего задаче, то надо вести речь об Elixir (Erlang).
А пока «ежики плакали, кололись, но продолжали жрать кактус».

[khim]

Проблема в том, что C++-разработчиков мало (про Erlang и говорить не стоит), а JS-разработчиков много. Тяжёлое наследие нулевых. Может лет через 10 всё и изменится, а пока — так.

[martynovich]

Тоже такой вопрос возник.

[grigoryvp]

Потому что из облака всегда можно сделать HTTP запрос к вашему собственному бэкенду, который ограничен только вашим воображением. Ну и если клиенту понадобится больше — пишите, посмотрим чем можно помочь. Вообще 16 мегабайт для облачного JS сценария в 100 строчек это довольно много.

[Druu]

> Кстати, Webpack рассчитан на комбинированный подход: вначале tree shaking во время сборки бандла, а затем dead code elimination с помощью UglifyJS плагина.

Вебпак сам по себе не выполняет никакого tree shaking, он только расставляет аннотации, которые потом используются в UglifyJS. И на данный момент это не работает из-за того, что аннотация над IIFE (в которую компилируются классы) не ставится.

[grigoryvp]

Это точно к последним версиям двойки относится? Потому что https://webpack.js.org/guides/tree-shaking/ — пример оттда компилируется и убирает код без UglifyJS плагина, которого по умолчанию нету. Или я что-то неправильно проверил?

[Druu]

Действительно, видимо функции обрабатываются отдельно.

Вообще, вот issue:
https://github.com/webpack/webpack/issues/2867

Там много про тришейкинг.

[grigoryvp]

Все верно, не просто так я эту статью написал. Там все печально :) Пока печально. Но подвижку к улучшению есть!

[Druu]

> Все верно, не просто так я эту статью написал. Там все печально :) Пока печально. Но подвижку к улучшению есть!

Еще печальнее, когда начинаешь пробовать предложенные там воркэраунды — например, babili у меня собирает проект на ~15клок около получаса и выжирает примерно 8гб памяти (а с дефолтными настройками ноды так и вовсе падает из-за недостатка памяти) :)
Но, да, верим в светлое будущее :)

[Druu]

Нет, погодите, там же после обычной компиляции остаются обе функции, только к нужной как раз и добавляется unsused_harmony-аннотация. А потом уже после node_modules/.bin/webpack --optimize-minimize main.js dist.min.js этот кусок удаляется из бандла, но --optimize-minimize как раз и активирует UglifyJs:
https://github.com/webpack/docs/wiki/optimization
Так что все верно.

[grigoryvp]

О, круто, они аглифай в комплект включили!