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
This helps to provide more information to a minifier for code reduction.
Implementation
Add @__NO_SIDE_EFFECTS__ annotation for function definitions
Add @__PURE__ annotation for callee site
Unresolved Questions
We need to add them carefully.
If we supply them, a minifier trusts their information for code reduction. This means that this effort would lead a bug. It might be hard to reproduce or detect because an user would run minifier only in a production/release build.
At least, we cannot mark map() method as @__NO_SIDE_EFFECTS__. We think and provide map() as that its transformer argument does not have any side effect ordinally. But an user probably pass any functions that do something having a side effect wildly and we don't have any way to detect and disallow them.
If there are some demands from user, we may have a benefit to do this.
But I suspect that we need to wait and see the progress about their annotations (e.g. specification, or inventing a lint rule and push into ESLint).
Furthermore, our implementation uses a function declaration syntax for all to define APIs. Of course, this does not help to provide a complete information for code reduction with less computation but their syntax is easier to reduce than function expression + variable declaratio like const bar = (val) => { ...} , I think.
Motivation
This helps to provide more information to a minifier for code reduction.
Implementation
@__NO_SIDE_EFFECTS__
annotation for function definitions@__PURE__
annotation for callee siteUnresolved Questions
See also
#__NO_SIDE_EFFECTS__
annotation for function declaration rollup/rollup#5024#__NO_SIDE_EFFECTS__
comment from Rollup evanw/esbuild#3149The text was updated successfully, but these errors were encountered: