aurelia/polyfills

async/await in IE 11 doesn't work

Closed this issue · 18 comments

When running my app in IE, it sticks at loading the app with the following error:

INFO [aurelia] Aurelia Started
Potentially unhandled rejection [1] TypeError: Object.getOwnPropertyNames: argument is not an Object
at createWithSymbols (eval code:50:7)
at descriptor.value (eval code:169:7)
at create (eval code:4:3)
at wrap (eval code:25:7)
at runtime.async (eval code:122:7)
at activate (eval code:85:25)
at tryActivateViewModel (eval code:3891:5)
at $ (http://localhost:9000/jspm_packages/system-polyfills.js:4:8727)
at H (http://localhost:9000/jspm_packages/system-polyfills.js:4:8314)
at R.prototype.when (http://localhost:9000/jspm_packages/system-polyfills.js:4:12046)

I've discussed this issue with Souldrinken, and he gave me the advice to import core-js before importing aurelia-bootstrapper, like:

System.import('core-js').then(function () { return System.import('aurelia-bootstrapper'); });

Can you provide a repro for this? Also...I would need some more information about how async/await relates to this. That feature may rely on additional polyfills, for example.,

This may already be fixed. We'll have some updates tomorrow.

I'll check today if the updates help solve this problem.
With repro do you mean a plunker example?

I can show you the code where it all happens:

async activate() {
if(!sessionStorage.getItem('patientsJSON')) {
await this.http.get(this.config.get('api_url') + "Patients").then(response => {
sessionStorage.setItem('patientsJSON', JSON.stringify(response.content));
});
}
if(!localStorage.getItem('nomenclaturesJSON')) {
await this.http.get(this.config.get('api_url') + "Nomenclatures").then(response => {
localStorage.setItem('nomenclaturesJSON', JSON.stringify(response.content));
});
}
if(!localStorage.getItem('citiesJSON')) {
this.http.get(this.config.get('url') + "data/cities.json").then(response => {
localStorage.setItem('citiesJSON', JSON.stringify(response.content));
});
}
}

I have this in my app.js. Everything runs fine in IE when adding the following lines in index.html:

System.import('core-js').then(function () { return System.import('aurelia-bootstrapper'); });

But I have also some problems bundling the app, it keeps looking for core-js. Even if I add it to the bundles.

I think the main issue here is something with polyfills? I hope this get solved so I don't have to import core-js.

It's not the code from your app that I need, but a simple reproduction. I have to be able to reproduce it in the skeleton app or else we can't figure out how to fix it.

I've created a repro, how can I share this with you?

If you can just attach it to this issue that would be fine.

Hi Rob, did you get the chance to solve this issue?

@jdanyow Do you have time to look at this IE issue? There's a repro linked above.

@sailo89 this is the current status right?

I have this in my app.js. Everything runs fine in IE when adding the following lines in index.html:
System.import('core-js').then(function () { return System.import('aurelia-bootstrapper'); });
But I have also some problems bundling the app, it keeps looking for core-js. Even if I add it to the bundles.
I think the main issue here is something with polyfills? I hope this get solved so I don't have to import core-js.

If so, please close this issue, and open a new issue in the bundler repo with the new error details. I'm guessing the problem is something to do with not bundling the babel runtime.

Hi, I was about to open an issue when i saw this one..
I'm having the same/similar problem.

I'm brand new to aurelia (and to webpack to an extent) so I'm a bit lost on this, as I tried a couple alternatives, all with the same outcome.

I'm using the webpack skeleton.

I added the webpack plugins to transform so they could compile to module ( I also tried the other plugin to asyn-to-generator )

webpack.config.js

{ test: /\.js$/, loader: 'babel', exclude: /node_modules/, query: { presets: ['es2015-loose', 'stage-1'],  plugins: 
        [
            ["transform-async-to-module-method", {
              "module": "bluebird",
              "method": "coroutine"
            }],    
            'transform-runtime',
            'transform-decorators-legacy'
          ] } 
      },

Then I simply added a small exapmle to the welcome.js submit()

 submit() {

    ///"BREAKS ON IE""
    async function sleep(ms = 0) {
      return new Promise(r => setTimeout(r, ms));
    }

    async function conversation () {
      console.log("llalal")
      let hi = await sleep(1000)
      console.log(hi);
    }
    conversation();
    //END OF "BREAKS ON IE"

    this.previousValue = this.fullName;
    alert(`Welcome, ${this.fullName}!`);
  }

On IE11 I always get the same exception, being thrown in aurelia-polyfills.js
I don't have to actually call any async function, the exception is thrown just be having the function defined.

Which leads me to believe its not actually async wait problems but some bug in aurelia's polyfllls.

I really would rather not import core-js just for this :(

I setup the project here with the problem.

http://imgur.com/fLWGXyQ, Here's a screenshot of the exception being thrown on IE11

@jdanyow Any way I can get a hand about this :) ?

We also have this problem: after upgrading to the latest Aurelia version and switching to Babel 6 we got "Object.getOwnPropertyNames: argument is not an Object" in IE 11 (it worked in Chrome).

Adding:
System.import('core-js').then(function () { return System.import('aurelia-bootstrapper'); });
bypassed the problem, but we are looking for perm solution.

We use async/await in our code.

If you can help us track down the issue, we can get a patch out asap.

How we can help with this?

If you can track down which polyfill is causing the problem and identify a fix that would help. If you are able to submit a PR, we can even get the release out the same day as the PR is submitted probably.

I wasn't able to reproduce this. If someone wants to fork one of the skellys and put together a repro that we can npm install;jspm install;gulp watch it would speed things up.

Looks like this issue has been resolved through various fixes.