feat: assignment literal analysis and truthy functions - #6452

@cyyynthia is attempting to deploy a commit to the rollup-js Team on Vercel.

A member of the Team first needs to authorize it.

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 98.77%. Comparing base (95c2f02) to head (b6d5e37).
⚠️ Report is 40 commits behind head on master.

⚠️ Current head b6d5e37 differs from pull request most recent head 156aef8

Please upload reports for the commit 156aef8 to get more accurate results.

@@            Coverage Diff             @@
##           master    #6452      +/-   ##
==========================================
- Coverage   98.78%   98.77%   -0.02%     
==========================================
  Files         275      275              
  Lines       10820    10825       +5     
  Branches     2886     2891       +5     
==========================================
+ Hits        10689    10692       +3     
  Misses         89       89              
- Partials       42       44       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Hmmm, isn't getting rid of polyfills in core-js actually a bad thing? After all, it is polyfilling missing prototype methods. From the diff it looks to me like your change might actually break the copyWithin polyfill. I believe it was for those reasons we never did the last step to mark some things as truthy (though of course negligence is likely the other reason).
At the very least what you must not do is add any logic that could give the impression that any of the assumed-present global/prototype methods actually exist, exactly not to break polyfills. It is fine to assume that objects or functions that the user declares are truthy, or methods in objects that the user declares.

At the very least what you must not do is add any logic that could give the impression that any of the assumed-present global/prototype methods actually exist, exactly not to break polyfills. It is fine to assume that objects or functions that the user declares are truthy, or methods in objects that the user declares.

I think this is a fair point, though perhaps we can preserve this new behaviour as an opt-in config flag instead 🤔

I think this is a fair point, though perhaps we can preserve this new behaviour as an opt-in config flag instead 🤔

I thought about this long in the past and I keep coming back to the fact that the only good reason why one would want to check the truthiness of a built-in prototype method is to do feature-detection, and we must not break those flows.
So there are several ways to do feature detection:

• Truthiness as a smoke test if there is something at a given prototype value, this we should never break
• typeof checks. We are not doing anything here at the moment, but in the future, we should not blindly assume that a prototype function returns function for a typeof call
• just calling it in a try-catch. While our logic assumes many builtins have no side effects, the try-catch-deoptimization will still preserve the call in those situations