Meta: important issues for 2.0 RTM

[jods4]

I am using this issue to list issues I've seen in our repos that I think should be closed before we officially go from 2.0 RC to RTM.

• Does not respect DllReferencePlugin, leading to oversized bundles #109 The CLI template for DLL is missing AureliaPlugin.
• Templating creates unwanted custom elements templating#549 + An anchor tag in dialog-body causes infinite loop dialog#283 critical issue with unwanted custom elements being created. The bug has existed for a long time but combined with Webpack renaming of exports it leads to <a> or <b> being custom elements!
• Dynamic Aurelia dependencies pal#21 make sure all core libs work well out-of-the-box (almost complete)
• Add docs to hub
• Update skeleton, cli templates, others?
• babel-polyfill breaking aurelia-polyfill on IE11

Don't hesitate to comment if you find other important bugs.

[niieani]

I've fixed remaining skeleton issues.

One thing to keep in mind is the automatic babel-polyfill still breaking aurelia-polyfill on IE11. We should probably do something about this before RTM.

[jods4]

@niieani I'm planning to try to ease polyfilling in RC-3.

That said wasn't the issue with babel-polyfill an imcompatibility with polyfills, i.e. it should come down to configuration?

[niieani]

@jods4 The thing is, one either uses babel-polyfill or one doesn't. Not sure if there any configuration that could turn off that specific, faulty polyfill from being included.

[jods4]

I mean: if you include babel-polyfill and disable aurelia-polyfill (there's a webpack option for that) you should be fine?

What else can we do?

[niieani]

I guess so, but you mentioned it wouldn't be possible because of the order in which Aurelia is loaded (entrypoints get loaded too late).

[jods4]

It's possible but complicated in RC2, that's what I'd like to improve for RC3.

[niieani]

OK! Sounds good.

[JeroenVinke]

Should aurelia-testing use PLATFORM.moduleName as well?

[niieani]

@JeroenVinke that depends if you run it under NodeJS (like testing via Jest) or in the browser through Webpack (like the Karma testing in Skeleton). To be safe, it's good to always wrap your module paths in PLATFORM.moduleName. I don't think we have any modules being dynamically loaded in aurelia-testing itself, so it's just about consuming the library in tests.

[JeroenVinke]

@niieani that makes sense. The CLI uses aurelia-testing in the browser: https://github.com/aurelia/cli/blob/master/lib/resources/src/main.ts#L13-L15. I was hoping that we could the same for the webpack applications that it generates, This works fine for now though:

    new ModuleDependenciesPlugin({
      "aurelia-testing": [ "./compile-spy", "./view-spy" ]
    }),

[jods4]

You can safely use moduleName everywhere, because aurelia-pal actually implements it as:

function moduleName(id: string, options?: object) {
  return id;
}

[jods4]

@niieani Better entry point management is committed to RC3 branch. Now, if you include babel polyfills in the entry point hopefully it should work fine. Would be nice to get a confirmation. On top of that disabling Aurelia polyfills should also work.

[kevmeister68]

In my experimentation, core-js also breaks aurelia-polyfill with respect to the Map polyfill from memory.

[valichek]

@jods4 trying to use layoutView in routes
tried

{ route: 'some',  moduleId: PLATFORM.moduleName('./pages/empty'), layoutView: PLATFORM.moduleName('./pages/_resources/layout-main.html')}

and

{ route: 'some',  moduleId: PLATFORM.moduleName('./pages/empty'), layoutView: './pages/_resources/layout-main.html'}

no difference, still getting error Error: Unable to find module with ID: ./pages/_resources/layout-main.html

from webpack:
[pages/_resources/layout-main.html] ./src/pages/_resources/layout-main.html 49 bytes {7} [built]

How to fix it?

[valichek]

So I fixed it with PLATFORM.moduleName('pages/_resources/layout-main.html'), is it bug?

[jods4]

@valichek
Thanks for the report.

Relative paths ./ sometimes work differently in aurelia-loader at runtime and Webpack, which leads to annoying errors. This is why I advise to use absolute paths like pages/_resources/layout-main.html as it works more consistently.

That said, I think you might have dug a real bug here, likely in the router code.
What is nagging me is that the loader is looking for ./pages/.... Notice the dot in front. At this point, the loader should be trying to load a normalized (absolute) module id, so my guess is that normalization is missing from Aurelia code somewhere.

I'll try to get someone who knows this code better than I do to have a look.

Anyway, you're better off using absolute names in your Webpack application. ;)

[valichek]

@jods4 sure, another thing is that I got the example of including modules from webpack skeleton. So it's better to fix this in skeleton too https://github.com/aurelia/skeleton-navigation/blob/master/skeleton-esnext-webpack/src/app.js#L7-L9
@niieani, please, check it

[jods4]

The babel stuff should be ok in the newest release, can someone confirm we can check it off the list?

[Alexander-Taran]

@bigopon RTM happened..