Open IObert opened 2 years ago
To be honest, I don't see how the current module layout would prevent tree shaking in general. If you refer to MessageBox
in your code, nothing from the default export of MessageBox
can be omitted by tree shaking. If the sap/m/MessageBox
contains additional (named) exports which are not used, those can be omitted, even with the current layout.
If we would have the module layout that you propose above
import {MessageBox, Button, MessageToast, Select} from "sap/m";
tools could indeed shake the tree and a lot of sap/m
modules would fall down. But IMO, the remaining apples, sorry, modules, would be exactly the same that you do not refer to in the current verbose set of imports.
So I guess, your point is not really tree shaking, but writing less imports. That's a fair requirement and we indeed considered to add a layer on top of the current modules, most likely per package, not per library (means: one for sap/m
, one for sap/m/semantic
etc.).
I would hope/expect that such a layer just consists of re-exports, but we did not yet invest into it.
As a precondition, IMHO the babel-plugin-transform-modules-ui5 would have to recognise and dissolve such re-export modules and rather generate the corresponding individual module dependencies in the sap.ui.define
syntax.
So I guess, your point is not really tree shaking, but writing less imports.
Yes, you're right. I'm ok if this is currently not a prio for you and if it takes longer. I just wanted to report this to trigger a discussion/conversation about it. Thanks for the fast response :)
Hi,
I just noticed that (control) imports cannot use tree shaking atm.
This means you need to write a very long "import header" like:
and cannot simplify write some short and concise code like:
Are there any plans to support this in the future?