babel
[corejs3] Avoid injecting `"".split` polyfill when it's not necessary
Fixes https://github.com/babel/babel/issues/9196.
- Since
core-js@2is deprecated, I'm only fixing this corecore-js@3 - There are probably many more polyfills that can safely skipped with static analysis, but I don't have a list of them. This PR prepares the foundation, and PRs expanding the filter are welcome!
Actually, i wonder if there’s a way to delegate this knowledge to the package - that way, if it needs to change, Babel doesn’t have to care?
Well, those polyfill plugins are already package-specific and contain code specific to the polyfill (implicit dependencies between polyfills, support data, mapping from es features to import names)
Right, but they’re still under Babel’s aegis. it’d be great if the conditions under which the polyfill were applied were under the control of the shim author - which is the point of the es-shims getPolyfill convention.
I think this is a move in the right direction.
(Perhaps as phase 2,) I'd like to see calls like the following supported and covered by test(s) as well, because stuff is frequently passed around as variables rather than literals:
new String(string).split(".")
This would allow developers to easily tell babel it's a String, when Babel can't detect it for sure itself.
(Perhaps as phase 3,) I'd even suggest support for suppression by a comment like[1]: // NOPOLYFILL E.g.,
string.split(".") // NOPOLYFILL
or, inventing an expression, "comment-typing" ("comment-typedness"?) like
string.split(".") // String
P.S. [1] This could be considered as something inspired by unrelated libraries like NOPMD in: https://pmd.github.io/latest/pmd_userdocs_suppressing_warnings.html [2] This type of stuff isn't as good as what typescript provides, but could make JS stronger in competing with it...
Note that the polyfill is not for the "this", it's for the argument.
Note that the polyfill is not for the "this", it's for the argument.
In any case, it would be nice if cases like those mentioned in the OP under #9196 are handled (if not in phase 1, perhaps in phase 2 or 3):
new String(string).split("."); // ex. 1
var sa = typeof str == "string" ? /* it's now obvious that str is a String */ str.split(".") : null; // ex. 2
It seems to me in most cases, there would be a variable on the left (this) side & a string on the right (param) side. If that is handled in most cases, that would be a good state of affairs.
However, fairly frequently i end up with code that uses Constants.SOMETHING as param as well. If that could also be handled using detection like in ex. 1, ex. 2 above, etc., that would be an even better state of affairs.
P.S. Ditto for the following enhancement suggestions, perhaps in phase 4 in addition to handling of ex. 1 & ex. 2 above (or perhaps instead of trying to deduce the type as in ex. 1 & ex. 2 above):
string.split(Constants.SOME_STRING) // NOPOLYFILL
string.split(Constants.SOME_STRING) // String
Anyway, you guys decide. I'm just pitching in a bit...
Without literals or type information i don’t know how babel could reliably determine that.
it would be a very bad idea to encourage developers to annotate their code merely to ensure accurate presence or absence of polyfills; it’s far better to overinclude than underinclude.