Doesn't load template page in IE11 about dialog HOT 12 OPEN

I'm going to assume this is similar to my issue.
More specifically this is 'Promise' is undefined. Might I suggest changing the title?

I have a similar setup but I'm using

Library Version: 2.0.0

Here is a converstaion on Discourse

It seems as if Webpack Runtime gets to a point where the promise-polyfill seem to be no longer present. The irony though is that when the error is thrown it is caught by code in the promise-polyfill. At first I thought this was due to loading async chunks in WebPack. Once I got WebPack to bundle all of aurlie-dialog into a single chunk there was still a Promise undefined error just in a different place.

I have tried everything to get the promise-polyfill loaded before the run time. Move it to entry, create vendor entry, have it as a plugin and an entry, put import 'promise-polyfill' everywhere.

But the question is why at times the Promise is defined and other times it is not. But still puzzled as to why I would need to do to get promise-polyfill loaded first if the stack trace returns back to promise-polyfill. If it returns back to there then it had to be loaded before the run time in order to start from there. You then think Promise would be defined. IDK grasping for straws.

A solution is to put the following line in the index.ejs but that seems to be against the grain.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/lib/index.min.js"></script>

In aurelia-dialog this is where it starts

dialog/src/ dialog-configuration.ts
  private _apply(): Promise<void> {
    const renderer = this.renderer;
    const cssText = this.cssText;
    return Promise
      .all([
---->        typeof renderer === 'string' ? RENDERRERS[renderer]() : renderer,
        cssText
          ? typeof cssText === 'string'
            ? cssText
            : cssText()
          : ''
.
.
.

Which then calls ux: () => from the RENDERRERS.

const RENDERRERS: Record<string, () => Promise<RendererStatic>> = {
  ux: () => import('./renderers/ux-dialog-renderer').then(m => m.DialogRenderer) as Promise<RendererStatic>,
.
.

The above is compiled to this

ux: function () { return __webpack_require__.e(/*! import() */ "vendors.async~3e799143").then(__webpack_require__.bind(null, /*! ./ux-dialog-renderer.js */ "yfWE")).then(function (m) { return m.DialogRenderer; }); },

Which then calls the WebPack run time to resolve vendors.async~3e799143

__webpack_require__.e = function requireEnsure(chunkId) {
/******/ 		var promises = [];
/******/
/******/
/******/ 		// JSONP chunk loading for javascript
/******/
/******/ 		var installedChunkData = installedChunks[chunkId];
/******/ 		if(installedChunkData !== 0) { // 0 means "already installed".
/******/
/******/ 			// a Promise means "currently loading".
/******/ 			if(installedChunkData) {
/******/ 				promises.push(installedChunkData[2]);
/******/ 			} else {
/******/ 				// setup Promise in chunk cache
/******/ 				var promise = new Promise(function(resolve, reject) {
/******/ 					installedChunkData = installedChunks[chunkId] = [resolve, reject];
/******/ 				});
/******/ 				promises.push(installedChunkData[2] = promise);

It dies at // setup Promise in chunk cache when creating a new Promise
var promise = new Promise(function(resolve, reject) ....

But then you continue and you end up in the promise-polyfill try … catch

   try {
      ret = cb(self._value);
    } catch (e) {
      reject(deferred.promise, e);
      return

from dialog.

Thanks to @3cp we have a solution!

To me this is a documentation bug. Some where it needs to be noted that these changes need to be made in order for aurelia-dialog 2.0 to work with IE11.

To fix this issue you need to add the following alias under the Resolve section of webpack.config.js

'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umb/dialog-aurelia.js')

Here is an example of what the Resolve section should look like after a clean setup.

  resolve: {
    extensions: ['.ts', '.js'],
    modules: [srcDir, 'node_modules'],
    // Enforce single aurelia-binding, to avoid v1/v2 duplication due to
    // out-of-date dependencies on 3rd party aurelia plugins
    alias: { 'aurelia-binding': path.resolve(__dirname, 'node_modules/aurelia-binding') },
    alias: { 'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umd/dialog-aurelia.js') }
  },

from dialog.

Your two aliases should be just one alias with two keys. I am surprised nodejs didn't complain about the duplicated object key (alias) in your webpack config.

from dialog.

Good catch something like this

alias: {
  'aurelia-binding': path.resolve(__dirname, 'node_modules/aurelia-binding'),
  'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umd/dialog-aurelia.js')
}

from dialog.

aurelia-dialog v1 uses aurelia-loader (the abstration layer normalized module loaders) to load dynamic resources.

v2 switched to native dynamic import() statement to simplify the code. This is indeed a breaking change for IE11.

However the dialog UMD build did normalize import() to plain promise. By default, it should work on IE11.

But our aurelia-webpack-plugin tries to load all aurelia-* packages native-modules build in order to take advantage of some webpack features. For example, webpack can tree-shake esm format, but cannot tree-shake js code in other format. So it did not pick the good old aurelia-dialog UMD build.

In summary, IE should die :-)

from dialog.

Please review the above cli PR (will be released in couple of days).
This one can be closed.

from dialog.

I just did a review and found that the alias is not needed. Going back to what we did earlier when we put the promise-polyfill in index.ejs with a <script> tag it worked.

I'm going to assume that the changes to the promise-polyfill in webpack.config.js resulted in something similar to putting the polyfill into index.ejs.

I did a check by keeping the comments on the alias and it works. I also see in the IE11 debugger the native modules being loaded.

My only other suggestion is to keep the messaging consistent. One section it is commented out stating to Uncomment if using IE11 and the other section is not commented stating if you don't use IE11 to comment. Not that it matters because the alias is not needed I would suggest to just comment out the promise polyfill and have the message Uncomment if using IE11.

If this works with the promise-polyfill moved in the webpack.config.js then the alias and my PR for document changes are not needed.

from dialog.

Yes, it worked without the alias, but I saw many strange WDS error in IE11 console. That could be due to the webpack transpiled import() is not compatible with polyfilled promise. Please double check that.

from dialog.

Either way it will work. I have been working with my app with just the promise-polyfill change without any issues. I think the [WDS] Disconnect! error is a webpack-dev-server issue. The only time I have seen them in IE11 is when I stop the webpack-dev-server but leave the browser open. Then some times when I start WDS up the error continues to show in IE11. Furthermore I don't see them when I run the app using IIS Express or Kestral (My app is .Net) obviously because I'm not using webpack-dev-server at that time. I still stick with the idea that the alias is not needed and documentation does not need to change, just the way promise-polyfill is loaded.

from dialog.

Thanks for the inside. I thought those WDS errors was caused by import() chunks.

Let's keep the alias in CLI, it's by default behind comment (doesn't hurt much), so that users can still have something to try if they have other problems in IE11. This is just to be cautious, the import() might cause user some other issue if they adjust code split settings in webpack (but I am not a webpack expert to be certain).

from dialog.

is not needed I would suggest to just comment out the promise polyfill and have the message Uncomment if using IE11.

I will do that, that sounds a good default.

from dialog.

It was funny because I was thinking "What is this WDS". When I started to type Webpack-Dev-Server the light bulb went on. That and searching for WDS all results pointed to Webpack which I found odd at first until I realized what WDS is.

Always good to be cautions especially when it comes to dated browsers.

from dialog.