'Symbol' is undefined problem in ie11

[lykhatskyi]

babel/packages/babel-runtime/helpers/builtin/iterableToArray.js

Line 2 in e2c5f25

if (Symbol.iterator in Object(iter) || Object.prototype.toString.call(iter) === "[object Arguments]") return Array.from(iter);

getting an error in ie11,
Can we change this check?
A lot of clients are using different js validators that decrease app rating because of this error

[babel-bot]

Hey @lykhatskyi! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[loganfsmyth]

Note the builtin/ in the path of that file. That means you're passing the useBuiltins option. Specifically

When enabled, the transform will use helpers that do not use any polyfills from core-js.

Given that, it would be up to you to ensure that any necessary ES6 polyfills are available, or else avoid using syntax in Babel that would depend on ES6 functionality that hasn't been polyfilled.

[mrchief]

@loganfsmyth That sounds promising but doesn't solve the problem.

[csergiu]

avoid using syntax in Babel that would depend on ES6 functionality that hasn't been polyfilled.

then what's the purpose of Babel?

[mrchief]

then what's the purpose of Babel?

Babel will do the polyfilling for you. But if you say useBuiltins: true, and try to use modern ES6 features in an archaic browser like Internet Explorer, then you'll run into issues. You'll be fine in Chrome, Safari, FF for most part but again, you need to ensure you're not using any new features that are not adopted by browsers yet.

As far as my comment above goes, I solved it by using babel-polyfill. I was using polyfill.io which was causing the Symbol related issues. As soon as I switched to babel-polyfill, all of them went away.

[ljharb]

I don't see why polyfilling Symbol should be required - it's not actually shimmable (core-js's shim is actually a sham, because typeof can't be polyfilled).

Most of the babel helpers have guards ensuring Symbol exists; why does iterableToArray lack one?

[loganfsmyth]

That's totally fair. If someone wants to submit a PR I'd be happy to accept it.

[ljharb]

That’s great; one will be incoming very soon!

[kofifus]

Stuck with the same issue :(
What is the best way to solve this until above commits become part of the release ?

[latzt]

@kofifus All you can do is rely on a workaround. I have the same problem where babel compiles for (const cassette of cassettes) to Symbol.iterator. As long we are waiting for the PR you can write for (let i = 0; i < cassettes.length; i++) which works on IE11. But this is only one example for many ES6 features which could cause a problem.

[ljharb]

Our temporary workaround has been to manually patch the file generated pending the PR landing.

[nicolo-ribaudo]

@timtox You can use normal for-of and the assumeArray option of the @babel/plugin-transform-for-of plugin.

[latzt]

@nicolo-ribaudo Sorry for late response but thank you for the tip with the babel plugin. Is there a list of ES6 features which are not baked into the babel core and one must use a plugin to transform them properly for older Browsers?

[ljharb]

@timtox every single one that adds syntax :-)

[latzt]

Thank you :-)

[TomS-]

Still an issue for me too. I've had this come up recently.

[Talat-Da3at]

i tried importing
core-js --> error still exist
react-app-polyfill --> error still exist
babel/polyfill --> error still exist

[johnnywang]

So looks like the PR died out and then was closed out because it was never approved. Is anyone else taking a look into this?

I had to import Symbol and Array.from polyfills into my app to get around this, but those are causing their own IE11 issues as well, just fewer than this caused.

[qmegas]

Because of that bug I had to stop using for ... of loop. The original report was made on Mar 19, 2018, 2 years have passed and still no fix.

[nicolo-ribaudo]

This report is not about for ... of; it's about array rest/spread.

If you are not using iterators I assume that you are using for...of with arrays: didn't the assumeArray option of @babel/plugin-transform-for-of work for you?

I'm working on a fix for this issue which is smaller than the PR which was discarded: it only works with array and array-like objects. This should make it easier to land it.

[mikesherov]

@nicolo-ribaudo just wanted to say thank you so much for fixing this. Any idea when it may land in a stable version of Babel? My use case is indeed the rest spread use case, and the assumeArray worked for me (mostly), but I'd like to be able to get rid of transforming for-ofs this way.

[nicolo-ribaudo]

Hi Mike!

You can follow the PRs in https://github.com/babel/babel/projects/12 for updates.
Some of them will already be included in the next release (on Friday), but the pending on the timing some of them could shift to the next patch (no more than 2 weeks) or minor (about 2 months).

If you have any comments about those PRs, please let us know!

[nicolo-ribaudo]

This is fixed for all the iterables defined in the ECMAScript spec by #11263 and #11285.
We are still working on adding opt-in support for array-like objects, so that it can be used with DOM lists.

[mikesherov]

Great work!

We are still working on adding opt-in support for array-like objects, so that it can be used with DOM lists.

Would this also work for jQuery? My other use case is:

const [elem] = $('div');

EDIT: nevermind, sound like it will work, given this PR https://github.com/babel/babel/pull/11265/files

[cbratschi]

In which Babel release will this be shipped? So far I still see the failing version if assumeArray is false.

[nicolo-ribaudo]

Objects defined as iterable by the spec are supported starting from Babel 7.9.0. Array-like objects (which are not iterable, and technically shouldn't work with for-of) will be supported in 7.10.0.

[ljharb]

@nicolo-ribaudo fwiw arraylike objects don't need to work, just arrays, Maps, Sets, and strings.

[nicolo-ribaudo]

It should work with all the dom collections, that in old browsers are normal array-like objects. However, it will be opt-in since it's not spec-compliant.

[ljharb]

The DOM collections can't be identified beyond just by being arraylike? I'd expect their Object.prototype.toString to differ.