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

Most upvoted comments

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

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)

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.

Further activity, to stave off the bots.

Begone bot! The dark fire shall not avail you!

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

  • needing to support Internet Explorer
  • 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. šŸ¤ž

@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.

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).

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

Zero config my balls šŸ˜‚

@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 Thank you for your comment!! your comment was very helpful:)

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/

image

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 šŸ¤¦šŸ»ā€ā™‚ļø.

@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:

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.

TY @edm00se your plugin worked perfectly for me!

@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>