You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just noticed that (control) imports cannot use tree shaking atm.
This means you need to write a very long "import header" like:
import MessageBox from "sap/m/MessageBox";
import Button from "sap/m/Button";
import MessageToast from "sap/m/MessageToast";
import Select from "sap/m/Select";
and cannot simplify write some short and concise code like:
import {MessageBox, Button, MessageToast, Select} from "sap/m";
Are there any plans to support this in the future?
The text was updated successfully, but these errors were encountered:
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 :)
akudev
changed the title
Support for tree shaking
Support for importing multiple modules from a library with ONE statement
Nov 30, 2021
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?
The text was updated successfully, but these errors were encountered: