Is this project active?

[nikolasleblanc]

Seeing that the last active issue is from late September.

[TheLarkInn]

Hi yes this project is actively used in different places however the angular AOT plugin and @ngtools ships with its own template inlining feature. When I first created this project, I was not a maintainer of the webpack org. Since joining the webpack core team, this repo has been neglected a bit but I am open to PRs and features.

[GiuseppePiscopo]

I'm not up-to-date with angular-cli and @ngtools, so here I'm asking: what would be the alternative path to not use this loader anymore? Of course, still remaining with angular 2, webpack 2, typescript 2, ...

Thanks

[nikolasleblanc]

angular2-template-loader is great for JiT builds along with awesome-typescript-loader, also great for testing, but JiT builds are no longer acceptable production solutions given their longer than reasonable render times.

For AoT, @ngtools/webpack is used in place of the combination of awesome-typescript-loader and angular2-template-loader, and the AoTPlugin (shipped within @ngtools/webpack) takes care of your ngc compilation (ngc is a wrapper around tsc that a) transpiles your typescript, and b) does the Ahead-Of-Time compilation that is the namesake of AoT).

For example, here's my loader configuration for JiT builds and AoT builds:

exports.ts_JiT = {
  test: /\.ts$/,
  loaders: [
    'awesome-typescript-loader',
    'angular2-template-loader'
  ],
  exclude: [ /\.(spec|e2e|async)\.ts$/ ]
};

exports.ts_AoT = {
  test: /\.ts$/,
  loader: '@ngtools/webpack'
};

And my plugin configuration for the AoTPlugin:

const AotPlugin = require('@ngtools/webpack').AotPlugin;
...

exports.aot = new AotPlugin({
  tsConfigPath: path.resolve('./tsconfig-aot.json'),
  mainPath: path.resolve('./src/main.ts'),
  entryModule: path.resolve('./src/app/app.module') + '#AppModule'
});

[nikolasleblanc]

Should be noted though that apparently @ngtools/webpack can also handle JiT builds, I'm just used to this particular toolchain and it's been good to me. :) Much respect, @TheLarkInn.

[GiuseppePiscopo]

Hi @nikolasleblanc and thanks for your info!

My bad for not being clear: @TheLarkInn is doing a great job, was just asking him what is he suggesting, given the current "work overload" and progress in angular-cli .

Also (my bad again), I'm aware of JIT Vs AOT, and before some recent issues I had with awesome-typescript-loader and some I'm now having with angular2-template-loader, my team was happy bundling both a dev JIT build as well as an AOT production build, the latter also with angular-router-loader and lazy-loading (also waiting on next angular 4 to see some more improvements on tree shaking).

Now, it's a couple of days that we're stuck with these weird issues, in particular #50 and other similar listed here.

Back to your experience, if I got it right: angular-cli and/or @ngtools/webpack can take the place of awesome-typescript-loader + angular2-template-loader, both for JIT and AOT builds.

Q1: Is that right?
Q2: What happens to lazy-loading in that case?

Thanks for your help

[nikolasleblanc]

Back to your experience, if I got it right: angular-cli and/or @ngtools/webpack can take the place of awesome-typescript-loader + angular2-template-loader, both for JIT and AOT builds.

Yup. Just, personally, I stick to angular2-template-loader and awesome-typescript-loader for my JiT stuff, which is really just for e2e and testing since they compile faster.

Q2: What happens to lazy-loading in that case?

Pretty sure you can bring in angular-router-loader as part of your JiT build, and @ngtools/webpack handles lazy loaded routes for you when building AoT. See https://www.npmjs.com/package/@ngtools/webpack#features.

Recognizing the use of loadChildren in the router, and bundling those modules separately so that any dependencies of those modules are not going to be loaded as part of your main bundle. These separate bundles will be pulled out of the critical path of your application, making your total application bundle much smaller and loading it much more performant.

Re your issue #50, I commented there.

[nikolasleblanc]

Oh and I wasn't suggesting you were giving the LarkInn any grief, I just felt it was time for me to give him some props. :)