Unable to get property 'jscomp_symbol_toStringTag10' of undefined or null reference
chriszrc opened this issue · comments
This error is thrown here (and only in IE11, but that's also the only place the polyfill is being loaded):
o = e.getOwnPropertyDescriptor(r, "toString"), o.value = function () {
var e = i.call(this), t = this[Symbol.toStringTag];
Specifically, the t = this[Symbol.toStringTag];. The page is loading highcharts, which seems to be the library that is having trouble with this. This is part of a polymer project, in which this polyfill is part of the default export-
are you using 'use strict'; and naively concatenating files together, such that this highcharts function is incorrectly being ran in strict mode?
'use strict'; is at the top of the Highcharts library files so why is that a problem? I'll say this, I'm running into the same issue with webcomponentsjs in IE11 and they have 'use strict'; at the top of their webcomponents-bundle.js. Removing the 'use strict'; from their bundle fixes the issue, but I shouldn't have to be doing that, so there's something more going on here.
After some testing it looks like loading the core-js polyfills before webcomponentsjs fixes the issue since that applies their Symbol polyfill before webcomponentsjs polyfills Symbol using this polyfill. I think it's worth investigating and possibly taking some inspiration from their polyfill to help fix up this one.
@TimvdLippe you are a maintainer of webcomponentsjs and have done a commit to this polyfill, any thoughts?
@alienriver49 Sorry I am not familiar with this issue nor with the Highcharts library. If this polyfill does not work in strict mode, I think it is best to try and fix that. As far as I know, 'use strict'; is used in all modern projects now, so I would expect that we are not the only ones running into this issue.
@ljharb Yes, 'use strict'; was the issue, although I had to remove it not just from the highcharts lib, but also @TimvdLippe I had to remove it from the webcomponents-sd-ce-pf.js file as well, to get my web-component to work in IE11
@TimvdLippe most polyfills run in sloppy mode and require it; a file written in one mode must never be run in a different one. Modern build processes do not naively concatenate files; they bundle modules, and do not have this problem.
Sounds like this is answered.
So, the answer is if you are using 'use strict' mode, don't use this polyfill?
Your comment about modern build processes has nothing to do with the issue at hand. Rollup (literally called a "Next-generation ES module bundler") by default puts 'use strict' at the top of their bundles. Webpack will also put 'use strict' in it's bundle by default. So, it has nothing to do with bundling modules or anything like that. The problem is that this library assumes that 'use strict' is not in use, which is fine, but it should be put in the readme or something so it is clear to users.
No - your choice of strict mode applies only to that file. The answer is, don’t use an archaic build process.
I can assure you that zero bundlers - webpack and rollup included - put their entire file in strict mode, as that would break a ton of code. They put each module’s closure in strict mode, which is fine.
In other words, any tool that assumes everything is in strict mode is inherently broken. No note in the readme is required, because it would be true for the entire language.
Well rollup does put it at the top of the first function closure unless you set useStrict to false. webcomponentsjs uses rollup and that's why there's an issue.
That's the only reason I suggested putting it in the readme, so that libraries can know. Some of the biggest front-end frameworks - Vue, React, Angular, Aurelia, and many more - use rollup and have the same 'use strict' across everything, React even has it at the top of their file outside of that function closure, so I just thought it would be helpful.
I've opened a ticket in webcomponentsjs to work with them to address it. Thanks for the help.
@chriszrc you can probably reference that one for your issue - it will ultimately fix it.
That's an unfortunate default; is there any issue filed on rollup to fix that?
Sure, but it's a dangerous default - you should be forced to enable it if you want the unsafe behavior.
Apparently the Rollup maintainers arrived at a different conclusion. I personally am indifferent about it, but with recent changes to the platform like ES modules by default are strict, I don't think they made a bad choice per se. If you want to challenge their choice, I think it is best to raise an issue at https://github.com/rollup/rollup/issues