SAP / ui5-typescript

Tooling to enable TypeScript support in SAPUI5/OpenUI5 projects
https://sap.github.io/ui5-typescript
Apache License 2.0
201 stars 28 forks source link

Support for importing multiple modules from a library with ONE statement #318

Open IObert opened 2 years ago

IObert commented 2 years ago

Hi,

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?

codeworrior commented 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.

IObert commented 2 years ago

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 :)