-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add support for sideEffects
hint in resolveId
#2593
Comments
sideEffects also accepts an array of files with effects |
I see, this is good to know. Will need to check if my suggestion will be enough for rollup-plugin-node-resolve to supply the information. In theory, all resolutions should run through the plugin so it should be possible in theory but it might become complicated. |
Even for the array The webpack
I don't know whether Rollup should (or could) try to emulate that behavior for non-JS asset types. |
Does rollup respect |
Not yet, which is what this issue is about. Preliminary work on this has started but it will still take some time. |
Hi, does this have an estimated finish date? I have an issue might relate to this. I created a module with typescript and React, bundled by Rollup. React is peer dependency in this module. TSX syntax have been transpiled to I know there are several ways to resolve this. But I prefer use sideEffects field to make the module tree-shakable because I cannot remove the script tag on page. |
Not really, but the PR on Rollup side is now ready for playing around with it: #2844 What is missing for me is creating a PR for rollup-plugin-node-resolve to see if this works for the intended use case. But #2844 also gives you a user-facing option to control side effects, which should be enough for your use case. |
@lukastaegert I am sorry Lukas, I have experienced the following: I have created a package called
// library-a package.json
...
"dependencies": {
"library-b": "^1.0.0",
...
},
...
// library-a package.json with both library-b and library-c dependencies
...
"dependencies": {
"library-b": "^1.0.0",
"library-c": "^1.0.0"
},
...
// library-c package.json
...
"dependencies": {
"library-d": "^1.0.0"
},
...
Now, if I instead add the // library-d package.json
...
"sideEffects": [
"./src/polyfill.js"
],
... And rebuild Does this mean that rollup relies on the How does rollup determine whether a module has side effects or not? But for
I know this is a long comment, its aim is to clarify how rollup works under the hood. Thank you very much for your attention and for rollup. |
Rollup does not rely on the side-effects property for tree-shaking. However there are quite a few situations where Rollup is not able to determine if code has side-effects, and your library-d appears to be such an example. The polyfill of course is a side-effect, but there could be other ways the library is written that might be safe but Rollup is not sure about it. Here the As an end user, you can control this behaviour yourself by using the Also note that Rollup does not do usually do "module tree-shaking" except via this option. In its core, tree-shaking, at least if you take the origin of the word, has nothing to do with modules but is happening on statement level with the effect, that sometimes whole modules are removed and sometimes partial modules. The fact that |
@lukastaegert Thank you for your reply and for the links.
import "./polyfill"; // This is the polyfill mentioned in my comment above (`src/polyfill.js`)
import someFunc from "./someFunc";
import anotherFunc from "./anotherFunc";
import yetAnotherFunc from "./anotherFunc";
...
export default someFunc;
export { someFunc, anotherFunc, yetAnotherFunc }; So in this case, On the other hand, with the Does it work like this? Then, import { someFunc } from "library-d"; // Uses stuff from library-d
...
export default aFunction;
export const someObject = {
...
}; But as there isn't any import which looks like This is the thing I am trying to understand. Thank you! |
Well, except that there is no assuming taking place, especially not by the pugin:
Well, with the sideEffects property, it adds the flag to signal Rollup: "If no import from this module is used, consider it and all its dependencies as having no side-effects". So essentially this means that we assume "./polyfill" has no side-effects either unless some other code imports it as well.
How an import is written and whether or not bindings are imported has nothing to do with side-effects. It just means we do not import a binding. If the sideEffects flag is not specified, Rollup will again do the deep analysis of all statements to find out if there are side-effects. |
Thank you! |
Feature Use Case
Taken from #2415 (comment)
Many packages include hints in their package.json files if executing the module without any imports does have any side-effects. Having this information could have a serious positive effect of bundle size while improving bundling performance. As rollup itself does not read package.json files, rollup would need to provide a way for plugins to provide that information.
Feature Proposal
My suggestion is to extend the
resolveId
hook to have the following form:In case
sideEffects: false
is provided as additional information, rollup would not include any code from the module unless exports from this module are included. Not sure how easily this could be implemented internally.The text was updated successfully, but these errors were encountered: