Symbol polyfill returns strings, creating issues for other libraries

Hi 👋

It seems like GCC ships a low-fidelity Symbol polyfill that returns strings. This has broken numerous libraries, including React, which assumes that if Symbol and Symbol.for exists, the typeof of the returned value is not string (popular polyfills like core-js return objects).

Unfortunately this issue isn’t isolated to GCC apps. Some Google SDKs (notably, Google Maps SDK) are compiled with GCC, polluting the environment with this polyfill. This is currently breaking every React website that uses Google Maps API in IE11 (https://github.com/facebook/react/issues/13414).

React assumes that if Symbol and Symbol.for exist, typeof Symbol() will never be a string. Violating this leads to very confusing errors for React users. It’s not obvious at all that loading a Maps API will install a low-fidelity polyfill into the global environment.

While arguably both string and object values for typeof are wrong, in practice Symbols most commonly need to be differentiated from strings — because both can serve as keys. So typically the value is tested as typeof something === 'string' to disambiguate them (because checking it for 'symbol' inside a library would only work with native Symbols). Therefore in practice making the typeof value an object creates less footguns — and has been used by popular polyfills like core-js for a few years.

Happy to provide more details if necessary! You can also find a reproducing project (caused by Google Maps being compiled with GCC) here: https://github.com/jamiewinder/ie11-fragment-issue

[gaearon]

Thanks, I’ll note that in the issue. That said it’s not always easy because typically main polyfills are bundled with app’s JS, but app’s JS expects any libraries (like Google Maps) to already have been loaded.

[brad4d]

Some notes:

1. closure-compiler does not provide a polyfill for Symbol.for.
2. closure-compiler’s polyfills in general are designed so that if the thing being polyfilled already exists, it is left alone and not replaced.

Given the above, if Symbol.for exists, then our Symbol polyfill should be disabled. So it should be correct that if Symbol.for exists then Symbol() will always return an actual symbol.

Is it possible that there’s another polyfill running on top of ours here?

1. closure-compiler Symbol polyfill runs early.
2. another polyfill library loads later and tries to add Symbol.for to our Symbol.
3. Stuff is broken because the later library assumes it is building on its own Symbol implementation.