sodatea / get-current-script Goto Github PK

const will not work for IE11-

This is an issue introduced in v1.0.1 11 days ago, not an issue in v1.0.0

https://caniuse.com/#search=const

Vue includes your polyfill

https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli-service/lib/commands/build/setPublicPath.js

But when I try to use document.currentScript in any js script when in IE11, I get a Out of stack space at

function getCurrentScript () {
    if (document.currentScript) {
      return document.currentScript
    }

Any idea what would cause this behavior?

Btw, the way I have it now is to load the original Adam Miller polyfill. Why would that end up running getCurrentScript() from yours?

I don't fully grasp this issue so I will try to be as comprehensive as I can. I can't share my code directly as it is proprietary. The use case is the following. I have a custom element that upon creation lazy loads a chunk (via dynamic import) that contains a Vue application built as a library, upon attaching to the DOM it instantiates the Vue application. This custom element and chunk are hosted on a separate, third party, domain than the main (legacy) application. The Vue application is built as a single chunk with no code splitting. The legacy application has a script that creates, and later attaches, an instance of the custom element via document.createElement('my-custom-element').

What tipped me of to a potential issue was that when the legacy application is executed in Firefox with the devtools an "InternalError: too much recursion" error is thrown. I tried understanding the issue but I am not familiar enough with the ponyfill to solve it. I have seen the following things that seem out of place in this use case.

It seems that the regex that figures out the domain of the script identifies the wrong domain in this case. The first few frames of the callstack are from the third party domain that hosts the custom element and Vue application chunk (that calls this library) but the last frames of the stack are from the domain of the legacy application that create the custom element. If I read the Vue code correctly found here the result produced here would set the publicPath to the wrong domain. This is not an issue for me since I only have a single chunk per Vue library.

If the correct domain was recognized the next issue would not happen. Assuming I am wrong and that the right domain is found in the previous step this lead to executing the following regex. This regex behaves badly when the document is large as it tends to be on legacy applications. I tried setting a breakpoint in Firefox and copy/pasting the result of document.docuentElement.outerHTML and searching it in VSCode with this regex, this just hangs VSCode. I also tried setting a breakpoint and executing .test(document.documentElement.outerHTML) from the developer console in both chrome and firefox with similar results. Breaking down the regex it seems straight forward enough so I am not sure why this presents an issue, however I am not an expert on regex engines.