es6 modules 3 - hoist commonly inlined modules

[spalger]

requires #6120

This transforms modules that are commonly inlined, like ui/modules, ui/routes, and html templates.

[epixa]

You're going to hate me.

I don't think we should use native imports for non-javascript files. One of the benefits of using es6 is the idea that eventually we'll be able to stop transpiling and rely on the native engine support, but es6 modules can only be used to import code from other javascript files. CommonJS will always require transpilation anyway, and it does support loading non-js files, so we might as well continue to use it for them.

[spalger]

Well, import visDebugSpyPanelTemplate from 'plugins/devMode/visDebugSpyPanel.html' is importing javascript which represents the original html file. With some future tool we can simply transform html files into javascript modules and continue to load them using the import system:

export default `
  <lots of html>
    <jazz></jazz>
  </lots of html>
`;

This is exactly what webpack is doing under the covers.

[epixa]

But that means that even though we're using native imports, we can't rely on any given import actually being statically analyzable native code, so to actually traverse any code statically we need to leverage webpack itself to do the analysis (which is what we have to do now) or build the files first.

This actually brings up a similar question that I've had for awhile: why not use the template cache that is built into angular to handle these templates rather than doing custom imports?

[spalger]

webpack itself to do the analysis (which is what we have to do now) or build the files first

I do think we will be building the files first. I can't see far enough into the future to think that will ever change.

why not use the template cache

In order to properly warm angular's template cache we would have to detect all of the urls of all of the required directives and create some pseudo module that runs first to make sure the cache is warm. Simply converting html files into JavaScript modules and requiring them feels a lot less complicated. I also really like the idea of having a single dependency management strategy, for code, templates, less, whatever.

[epixa]

LGTM