parcel: IE support: "'Promise' is undefined", bundles fail to load

🐛 bug report

Loading the dev server output in IE11 keeps bundles from loading. It’s a hard stop that prevents the base page from even attempting to continue.

Note: This is from what’s generated by parcel, not my app source code or my dependencies. See this comment below.

🎛 Configuration (.babelrc, package.json, cli command)

.babelrc

The app works in FF + Chrome (used --no-cache) without the custom .babelrc.

{
  "presets": [
    [
      "env",
      {
        "modules": false,
        "targets": {
          "browsers": [
            "> 1%",
            "last 2 versions",
            "ie 11",
            "not ie <= 10"
          ]
        }
      }
    ]
  ]
}

package.json

here's the full package.json, below is the scripts and deps only

  "scripts": {
    "clean": "rimraf dist",
    "dev": "parcel src/index.html",
    "build": "run-s clean build:raw",
    "build:raw": "parcel build --public-url . src/index.html",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "devDependencies": {
    "babel-core": "^6.26.3",
    "babel-preset-env": "^1.7.0",
    "npm-run-all": "^4.1.5",
    "parcel-bundler": "^1.10.3",
    "rimraf": "^2.6.2"
  },
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "ie 11",
    "not ie <= 10"
  ]

I start the local server with npm run dev, which invokes parcel ./src/index.html.

Note: my package.json includes the relevant browserslist, which specifies IE 11.

🤔 Expected Behavior

Bundles should load correctly, including in IE 11.

😯 Current Behavior

Bundled app stops loading in IE11 almost immediately. Cites “‘Promise’ is undefined” in JS console, clicking to the line number points to the loadBundles function, which returns Promise.all(bundles.map(loadBundle)).

Also used by Parcel’s generated main js file, Promise.resolve and fetch. Specifying IE 11 support for targeted browser should ensure that no un-polyfilled APIs are used (Promise, fetch).

Raw console error:

SCRIPT5009: 'Promise' is undefined
main.1f19ae8e.js 394,27)

parcel_ie_issues

💁 Possible Solution

From the other linked “ie support” descriptions in the changelog and the corresponding culprits, it looks like this is has to do fundamentally with the un-polyfilled Promise and global objects, such as fetch referenced when attempting to load necessary bundles. The loadBundles fires before my app logic, so no polyfilling on my end will affect the outcome. By performing a build of my repro with manually added polyfills into the head tag for Promise and fetch, this worked; but this isn’t something I should have to do.

🔦 Context

For my work apps am required to support IE11. I believe this should be achievable w/ parcel, but ran into some trouble. The app works great in Chrome and Firefox. The issues I’m experiencing deal with Parcel’s direct use of Promise and fetch directly in the initialization of bundles from the built main.<hash>.js.

💻 Code Sample

I have an example repo:

https://github.com/edm00se/parcel-ie11-issue-demo

Steps to reproduce:

git clone https://github.com/edm00se/parcel-ie11-issue-demo.git
cd parcel-ie11-issue-demo
npm install
npm run dev
open http://localhost:1234 in IE 11
have a look at the js console, since the screen is blank (screen shots above)

🌍 Your Environment

Software	Version(s)
Parcel	1.10.3
Node	10.13.0
npm/Yarn	6.4.1
Operating System	Windows 10

Thank You!

I love parcel, it’s a great and performant bundler that’s enjoyable to use. When I set out on this crazy path, I wasn’t expecting to get as far as I have, and I am 99.8% there!

*note: I’ve updated this description to point to a far more simple reproducible repo

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 9
Comments: 25 (2 by maintainers)

Commits related to this issue

fix(ie): implements manual polyfill for promise and fetch refs: #14 - this should address the loading issues for IE11, tested locally, but I won't merge this branch ever - the bundler (parcel) shoul... — committed to edm00se/modernize-ng1 by edm00se 6 years ago

Most upvoted comments

What’s the point on even having browserslist if it won’t work as expected.

+17

tomasdev on May 6, 2019

For any interested in this issue, I threw together a parcel plugin to add high level polyfills for both Promise and fetch to keep parcel’s bundle loader working in IE(11).

repo: https://github.com/edm00se/parcel-plugin-goodie-bag use: npm i -S parcel-plugin-goodie-bag (auto loads into index.html on build/dev)

+13

edm00se on Jan 22, 2019

Like stated in the comment, every npm package you use that isn’t commonjs should also have a browserlist or engines field in pkg.json to indicate what syntax the code is using. Otherwise parcel would need to assume that all modules need to be compiled if a target isn’t defined, which isn’t very good for performance.

DeMoorJasper on Dec 8, 2018

Further activity, to stave off the bots.

edm00se on Jul 23, 2020

Begone bot! The dark fire shall not avail you!

edm00se on Jan 20, 2021

In case it’s not clear from above, part of the reason I had issues was due to:

needing to support Internet Explorer
- I hate it
- Microsoft doesn’t even like it
- some of us poor saps are stuck supporting it due to contractual promises
babel-polyfill, which is the v6 babel package, doesn’t polyfill either Promise or fetch
- this appears to different for at least Promise with the v7 package, @babel/polyfill
- fetch polyfill will still be needed
- due to timing, pulling in a Promise polyfill is still be needed before our source code is hit
the app configuration of babel-polyfill fires after when Parcel will need it for a multi bundle scenario
- requiring in html partials seem to cause that scenario, due to multiple bundles being generated

I wish there was an easier way of doing this, making Parcel more intelligent regarding browser support detection and doing this so I wouldn’t have to. That said, it’s behaving with what it was given as far as configuration. With any luck that might change in the future, until then we can work with the situation. 🤞

edm00se on Jun 13, 2019

@tomasdev as a consumer of dev tooling, I agree.

I think what is central here is that parcel, at least v1’s approach, seems to try to provide default enabled and configurable “other tools”. My preference would look something along the lines of detecting the browserslist definition and determining whether to need to polyfill Promise and fetch early in its generated code, providing a virtually seamless experience.

edm00se on Jul 21, 2019

I’m confused 🤷🏻‍♂️-> isn’t the issue here that Parcel 📦 is trying to unpolyfilled Promise to load its bundles?

I understand running babel over modules which are not compiled down to es5, but isn’t the issue here that Parcel 📦 itself is trying to use the undefined Promise object?

Here’s what I did to test 🔬: parcel build src/index.html Tested in IE 11 =>produces error ❌ Added promise polyfill manually to dist/index.html ; as well as fetch Works ✅

To me, that suggests that Promise is being used by Parcel 📦 before its possible to polyfill it (as opposed to any of the dependencies actually causing the issue).

masterwaffle on Dec 10, 2018

Its 2021 and I still cant figure out how to get Parcel to work on IE11.

Zero config my balls 😂

gregg-cbs on Sep 30, 2021

@DeMoorJasper thanks. If you check my package.json, it includes a browserslist config which explicitly includes “ie 11”. I believe that’s all that should be needed. With that said, the generated output still attempts to use Promise.all, Promise.resolve, and fetch to load the generated bundles.

Is there something else I’m missing?

edm00se on Jan 13, 2019

@edm00se Thank you for your comment!! your comment was very helpful:)

kazan-de-sejong on Mar 21, 2019

I threw together a dead simple reproducible app, purely vanilla (no frameworks), but with configured babel which should match up with parcel’s requirements from the app source perspective. This shows the same behavior I described, with less surrounding clutter. Specifically, with more than one bundle, Parcel itself relies directly on Promise and fetch.

source: https://github.com/edm00se/parcel-ie11-issue-demo deployed: https://edm00se.codes/parcel-ie11-issue-demo/

edm00se on Dec 14, 2018

I also hit this very problem today - seems an issue with the pre-app serving code not the app code transpiling/polyfilling itself.

I was blown away 💨 by Parcel and how it completely simplified the build over webpack, but we pretty much exclusively target IE at work 🤦🏻‍♂️.

masterwaffle on Dec 8, 2018

See https://github.com/parcel-bundler/parcel/pull/2073#issuecomment-427610992

DeMoorJasper on Dec 6, 2018

@gregg-cbs Microsoft is doing almost everything it can to not support or be shackled to IE. It is ancient by all modern web browser standards and hasn’t received any feature updates since 2016, so I suggest that if your expectation is that it should be supported in 2021, perhaps you should revisit your expectations.

If you’re still set on making it work with IE, please note that this issue was created for Parcel v1, v2’s approach I wouldn’t expect to work with IE out of the box as Parcel is modern tooling and IE is anything but modern. I also suggest checking out the following:

I wrote a plug-in for parcel v1 that bundles two polyfills, a team I was on made use of this to get our contracted IE support met
try out parcel v2, which supports legacy bundles and makes it quite easy to eliminate the need for a plug-in like the one I just mentioned
if you’re set on being salty about demanding support for an ancient browser at this point of IE’s horrible death spiral, try something else

Closing this issue as there’s nothing further to be gained here. There are ways of making this work for v1, v2 makes it easy even though it’s not what should be a common use case now, and with the v2 RC out the API is mostly settled and the full release is on the horizon.

edm00se on Sep 30, 2021

TY @edm00se your plugin worked perfectly for me!

riverross on Feb 8, 2019

@masterwaffle That’s what I’m seeing as well.

Manually dropping polyfills for Promise and fetch into the head tag of my generated dist/index.html allows the bundles to load/work correctly in IE.

<script src="https://unpkg.com/es6-promise/dist/es6-promise.auto.min.js"></script>
<script src="https://unpkg.com/unfetch/polyfill/index.js"></script>

edm00se on Dec 10, 2018