Error in IE 11 when using latest @vue/cli to compile

[alexbet]

I am getting a "const not initiated" error in Internet Explorer 11 when building with the latest version of @vue/cli, and that breaks the code and I get a blank screen. I narrowed it down to superagent 4.1.0, no other package was problematic. When I reverted back to superagent 3.8.3, the error went away.

Any help is appreciated.

[fmal]

@alexbet same issue here, guess that #1423 by @niftylettuce would fix this

[niftylettuce]

I'll try to get #1423 released today.

[alexbet]

Any chance you can release this please? Thanks!

[niftylettuce]

Hello @alexbet and @fmal – v5.0.0 was just released to NPM and an updated README is now available here on GitHub (see https://github.com/visionmedia/superagent#superagent).

What's new

• Browser version is now only 19KB (that's 60% in file size savings from v4.x which was 48KB)!
• Codebase refactored using xo, prettier, remark, and more
• Browser compatibility linting via eslint-plugin-compat
• Browserslist integration (current targets are > 1%, last 2 versions, ie 9)

How to install

npm install superagent@latest

Or if you're using yarn:

yarn add superagent@latest

Polyfills

Please see the Required Browser Features section in the README if you plan to support IE 9 and/or IE 10 and use superagent.

[alexbet]

@niftylettuce I just installed 5.0.2, rebuilt the project, and I am still getting the "const not initialized" error. :(

Here is an example website where you can see the error in IE11:
http://aa.alexbet.net

[niftylettuce]

@alexbet can you please share what file/link to superagent you're using?

https://unpkg.com/superagent@5.0.2/dist/superagent.min.js

there is no const in that file anywhere :)

[alexbet]

I am not linking Superagent. Superagent is bundled in the vendors chunk by Vue.js from the node_modules install of Superagent when building the project. And yes, the installed Superagent version in node_modules is 5.0.2.

[alexbet]

When I go back to Supergent 3.8.3, it is working file. I am wondering if Babel is doing something to Superagent when it builds the vendor chunk. it is super frustrating!

[niftylettuce]

Can you share your configuration? How are you including Superagent? Are you using Browserify or Webpack? Babel? What's your config?

…

On Mon, Apr 1, 2019 at 6:50 PM Alex Betinski ***@***.***> wrote: When I go back to Supergent 3.8.3, it is working file. I am wondering if Babel is doing something to Superagent when it builds the vendor chunk. it is super frustrating! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1470 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAf7hWDdnmMBIyWSI5V1ppr02XFSbcL4ks5vcptCgaJpZM4cCcU8> .

[alexbet]

I am using Vue-Cli:
https://cli.vuejs.org/
Vue-Cli installs Webpack and Babel and builds projects with them.

[alexbet]

Here is my package.json file. What you can't see in it though are Webpack and Babel. This is because they, and their config, is included in the Vue-Cli installation. When you create the project with Vue-Cli, Webpack and Babel and other config is set by Vue-Cli. In the package.json file you can also see the browserslist config. Hope this helps.

package.json.zip

[niftylettuce]

Your bundler is to blame, if you want to explicitly load a pre-compiled browserified version that supports IE9+ then you need to require the dist version. Otherwise your bundler should convert const to var as needed.

[alexbet]

Thanks for the reply. I am not sure what changed in the newest versions, but don't a lot of people use this setup? Vue was the most popular Javascript framework for 2018 surpassing even React, and Babel and Webpack are used by all of the Javascript frameworks, Vue, React, Angular. So this problem can definitely affect a big chunk of your users.

I love Superagent and would not like to have to switch because of this problem. Just thinking aloud, if the problem is the bundler, then why isn't there a problem with packages other than Superagent? What does Superagent have that others don't?

[niftylettuce]

Every package that wants to support the browser would need to have a lib compiled directory that supports the browser, and specifically your specific version of the browser (e.g. your exact browserlist config). You're relying on every developer out there to adopt that approach. That is impossible.

[niftylettuce]

The key difference of Node vs. Browser when you require('superagent') via Webpack/Browserify versus Node, is that it references browser property in package.json. This property specifically tells the bundler that certain files won't work in the browser, so to use an alternate (e.g. to make a request, Node uses http package and in the browser we use xhr). This property does not relate to syntax of code, merely features.

Ref: https://github.com/defunctzombie/package-browser-field-spec

[niftylettuce]

In the previous version of superagent, we incorrectly were compiling relative to the browser. Therefore in Node environments, the files getting loaded from lib/ directory were polluted unnecessarily with a browser-specific targeted compilation.

[alexbet]

So are you saying that Superagent will now work only with Node and not in the browser?

[niftylettuce]

No, I am not saying that, it works in both environments just fine.

[niftylettuce]

A workaround for folks like @lorenzos and @alexbet is to do something like global: true in your Babelify config, or to compile twice, once for the browser using browserify, and then again with Babel and your specific .browserlistrc needs.

You should absolutely, absolutely NOT assume that all developers out there will bundle their distributed packages in NPM repository for your specific browserlist config needs. Some packages out there might only be compiled for IE10, others might only be compiled for IE9, etc. You should be the one doing the final compilation with Babel and your specific Browserslist config.

https://github.com/babel/babelify#why-arent-files-in-node_modules-being-transformed

[niftylettuce]

I'm going to actually compile the lib folder for the browser as well. After a lot of thought and use-cases that came up in other projects, it's feasible to have this pre-compiled in NPM for browser usage. You shouldn't need to do this workaround, at least with superagent in the next release.

However please make note that not all other developers are compiling their packages like this, so you should be very careful and also have a nice lint setup on compiled assets, not just the source code (my previous statement/comment still stands).

When I publish the next version I will post here again.

[niftylettuce]

🎉 v5.0.3 is released and fixes this issue cc @lorenzos @alexbet

You no longer need to reference const superagent = require('superagent/dist/superagent.js'), you can simply const superagent = require('superagent');.

[alexbet]

Works beautifully! Thanks @niftylettuce!

[niftylettuce]

Glad to hear