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)
š 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)
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
andfetch
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 intoindex.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:
babel-polyfill
, which is the v6 babel package, doesnāt polyfill eitherPromise
orfetch
Promise
with the v7 package, @babel/polyfillfetch
polyfill will still be neededPromise
polyfill is still be needed before our source code is hitbabel-polyfill
fires after when Parcel will need it for a multi bundle scenarioI 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 polyfillPromise
andfetch
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 abrowserslist
config which explicitly includes āie 11ā. I believe thatās all that should be needed. With that said, the generated output still attempts to usePromise.all
,Promise.resolve
, andfetch
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
andfetch
.source: https://github.com/edm00se/parcel-ie11-issue-demo deployed: https://edm00se.codes/parcel-ie11-issue-demo/
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 š¤¦š»āāļø.
See https://github.com/parcel-bundler/parcel/pull/2073#issuecomment-427610992
@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
andfetch
into thehead
tag of my generateddist/index.html
allows the bundles to load/work correctly in IE.