Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix #1791: mark certain "Set" and "Map" as pure
- Loading branch information
Showing
3 changed files
with
116 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d0b0874
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evanw String, Map and Set also implement side effect free iterators.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator#description
d0b0874
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evanw Set, Map, and Array all have mutable iterators by default, so you cannot assume that the iterators are always pure. Please undo this change.
Is it possible to statically detect when built-in default iterators are mutated? This optimization could be gated behind such a detection
d0b0874
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All JS bundlers and minifiers make basic assumptions about the code. If someone were to alter any core JS builtin in an incompatible way such as:
then they should disable optimizations altogether:
d0b0874
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general esbuild assumes that built-ins behave like built-ins. For example, esbuild sometimes makes use of
Object.defineProperty
which means you must polyfill it yourself if it doesn't exist and the polyfill is assumed to behave according to the specification. I'm not going to change esbuild's output to try to get it to continue to work in a bizarre environment whereObject.defineProperty
does something random instead of what it's supposed to do. Redefining built-ins to do non-standard stuff is terrible development practice. IMO it's reasonable that your tools are going to break if you do that. The fix is to just not do that.What use case do you have in mind? What library are you using that redefines built-in iterators to have side effects? What are the side effects, and why are they useful?
No, it's not possible. New code can easily be injected into the VM in lots of different ways including via
eval
,new Function
,<script>
tags, etc. JavaScript is a dynamic language, not a static language.