This library is not tree-shaking friendly

Environment

Tech	Version
@material-ui/pickers	3.1.1
material-ui	4.1.1
React	16.8.6
Browser	any
Peer library	date-fns 2.0.0-alpha.34

Steps to reproduce

Tree-shaking with code splitting is problematic due to unnecessary bundling by rollup for es and cjs targets

Expected behavior

Pickers should be packaged like material-ui core, especially pickers are under mui organisation. I am referring to

{
  "main": "./index.js",
  "module": "./esm/index.js",
}

they have in package.json. Notice, they give path to not bundled index.js files. However, for pickers paths target bundled library by rollup.

Rollup is nice for UMD target, but for cjs and es this is really redundant, people using bundlers on app level will bundle vendor files anyway. Prebundling hurts tree-shaking and does not give any advantage what so ever. Webpack tree shaking is based on unused reexports and prebundling library won’t have those but a flat structure.

Also, we cannot even do import like import DatePicker from @material-ui/pickers/DatePicker which would target a component with es module, because the only es file is bundled. This is problematic because of Webpack issue https://github.com/webpack/webpack/issues/7782 , so you cannot tree shake a given library across multiple chunks. The remedy is to import components like import DatePicker from @material-ui/pickers/DatePicker, but because this is not of es type, it leads to disaster because material-ui/core components are not imported as es modules, so actually they will be duplicated in date picker chunk.

So please, do not bundle for es and common js targets. And if you really want to bundle for those, do it additionally, but don’t link those in main and module in package.json

Actual behavior

As above

Live example

n/a

[klis87]

@TrySound here u are https://github.com/klis87/webpack-tree-shaking

Proof that tree-shaking works for core components and does not work for pickers

[klis87]

But then you make peoples life miserable. Please read arguments I made above. If you don’t wanna provide alternative builds, just don’t bundle for es/cjs targets. Not bundled esm is tree-shakeable and not bundled cjs files can also be run on server (why to bundle for server usage anyway?)

Please give me at least one argument for bundling for es/cjs with rollup. I gave you tons of serious disadvantages. Plus, you are under @material-ui org and they allow such imports, thanks to which they are friendly library to make optimisations, and I believe you should conform to their way, as pickers are now somehow official mui components.

From maintanance point of view not bundling is simpler than bundling, you just need to bundle for UMD and thats it.