Support webpack tree-shaking

Do you want to request a feature or report a bug?

Optimization

What’s the current behavior?

Currently slate is not tree-shaking friendly, at least not with Webpack

What’s the expected behavior?

Slate should be tree-shaking friendly, especially it is so big library.

There are several things to consider to make it work:

• sideEffects: false should be added to all package.jsons, unless there are side effects, then it should get array of modules with side effects
• why even bothering with using rollup for providing es build? In my opinion it does not give any advantage, because bundling is done on app level anyway. Prebundling though doesn’t allow webpack to make its optimizations, especially tree-shaking. Bundling with rollup/webpack is great for UMD though

Why do I need that? Because I code-split my app, and I wanna display WYSIWIG only in certain cases. However, I need access to { Value } to deserialize json from db to display generated documents, and right now whole slate is bundled just to get this one object. I cannot even pick this object from slate/models/value, because simply slate is prebundled by rollup.

Problem is related to blog post https://www.danielberndt.net/blog/2018/you-might-not-need-rollup-for-libraries/

Also, one of libraries optimized for webpack tree-shaking is material-ui, giving just for reference.

[klis87]

@dmitrizzle thx, I will try it perhaps but I have one idea first I need to investigate mitigating tree-shaking issue

@ianstormtaylor

1. I am not sure how 2495 is related? the only thing I can see is that immutable wont be needed anymore which takes quite a few a kbs
2. Indeed I managed to use slate-react inside dedicated bundle only needed for WIZARD rendering, I am addressing slate in this issue, as I need ONLY Value in bigger part of the app, while I end up to have whole slate because of that
3. what do you mean by any restructuring? slate is structured already fine now, it has index.js with reexports, which is just what webpack needs, the only 2 things needed to be done are: a) adding sideEffects: false to package.json b) giving up rollup for es build - babel is totally enough I tested this locally and it did work

The biggest question of all is, is slate safe to apply sideEffects: false?

[klis87]

Good news regarding serialization.

However, I still thing it is worth considering giving up rollup for es/cjs build. Correct me if I wrong, but as stated above, I cannot see any advantage.

Regarding sideeffects, it is still possible to provide array of files with sideeffects instead of false.

In my free time I will try to hunt down those files, @ianstormtaylor do we have any branch which assembles stuff which will go to the next version? if not, I could do it then, as I guess that removing immutableJS is a complete slate rewrite