Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
IObert opened this issue Nov 30, 2021 · 2 comments
Open
Labels
enhancement New feature or request types ES modules types (recommended)

Comments

@IObert
Copy link

IObert commented 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:

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
Copy link
Member

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
Copy link
Author

IObert commented Nov 30, 2021

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 akudev changed the title Support for tree shaking Support for importing multiple modules from a library with ONE statement Nov 30, 2021
@petermuessig petermuessig added the types ES modules types (recommended) label Dec 1, 2021
@akudev akudev added the enhancement New feature or request label Dec 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request types ES modules types (recommended)
Projects
None yet
Development

No branches or pull requests

4 participants