Slow rebuilds after upgrading to webpack 2.1.0-beta.23

[asadsahi]

Managed to upgrade asp.net core spa project to webpack 2.1.0-beta.23 and it is running fine. However, not sure if this issue is with webpack 2 or my project settings, hence pinging @SteveSandersonMS and @TheLarkInn to have a look at this project, where rebuild starts quite late and actually builds slow as well:

In order to run with upgraded version, please switch to rebuilds branch.

Here is the current rebuild stats on my machine:

My project: based on webpack 2.1.0-beta.23

Compared to a fresh asp.net core spa project created from yo: based on webpack 1

Difference is quite large.

Greatly appreciate the time to have a look at this issue and point out the possible cause of this.

[TheLarkInn]

Is this using angular2 hmr or just css HRM capabilities? @sokra if you can weigh in.

[MarkPieszak]

It looks like he isn't using Patricks angular2-hmr or anything @TheLarkInn

Just the basic stuff module.hot stuff:

if (module.hot) {
    module.hot.accept();
}

@asadsahi You might need to update your module stuff to the latest from this repo, possibly it's not disposing correctly?

I haven't tested this repo with wp2 beta yet, so I'm not positive.

// Enable either Hot Module Reloading or production mode
const hotModuleReplacement = module['hot'];
if (hotModuleReplacement) {
    hotModuleReplacement.accept();
    hotModuleReplacement.dispose(() => { platform.destroy(); });
}

[asadsahi]

@TheLarkInn as Mark mentioned it isn't using angular2 hmr, just the webpack's build in HMR capability.

One thing I have clarified in the issue above is that fast rebuild is a webpack 1 based project, but slow rebuild is a webpack 2.1.0-beta.23 project.

@MarkPieszak tried with above settings, but getting "platform is not defined".

Strange thing with this project's HMR is that it detects the change very late, I mean:

Initially, when we get: [HMR] connected

After that, when code changes, [HMR] bundle rebuilding message appears after 2-3 seconds, and thats what's adding the delay in rebuilding I guess, not sure if that helps narrowing problem down.

[SteveSandersonMS]

Sorry, I don't know. If you can supply repro steps in the form of a minimal set of changes to the default Yeoman-generated project output then I'd be happy to have a look, but there are too many changes in this project to pin down a cause.

[SteveSandersonMS]

I'll close this as it's not an issue with the templates as they are (they use Webpack 1) but if you can identify a fault please reopen this with details. Hope that's OK!

[sokra]

hotModuleReplacement.accept(); doesn't work, it must be statically anlysable module.hot.accept.

It actually works in this case, but don't do it

[SteveSandersonMS]

@sokra It does work in Webpack 1. Is this a change in Webpack 2?

[sokra]

no, it works without argument, but hotModuleReplacement.accept("./file") will break.

[asadsahi]

@SteveSandersonMS There are quite a number of changes compared to original generator, including catering of some breaking changes since Webpack 2 beta.23

e.g:

1. no empty extension available in webpack 2 now so extensions: ['.js', '.ts'],
2. Change of loaders > rules property in webpack module configuration
3. Addition of SCSS loader
4. changing ts-loader with awesome-typescript-loader
5. Also, added, unsafeCache: true option as @sokra mentioned in one old issues to try this to speed up builds, but that doesn't make any difference.
6. Some peer dependencies of webpack 2 upgrade as well.
7. Changing require('') > imports in polyfills.ts
8. Removed server rendering with Universal

[SteveSandersonMS]

@sokra OK, replaced with direct references to module['hot']. After TypeScript compilation, this will look like module.hot in the JS code, so I guess whether or not this works depends on when Webpack's static analysis runs (before or after ts-loader).

[asadsahi]

@SteveSandersonMS what I sensed from your comments is that there is no tight dependency of Webpack 1 the only option in dotnet core spa generator which may have caused this? Means, it is safe to upgrade client build tools if someone have to?

[SteveSandersonMS]

That's right. I'm not aware of anything locking you to Webpack 1 (but of course if you choose to upgrade, you will need to figure out solutions for any breaking changes introduced in Webpack 2).

We'll make the switch to Webpack-2-by-default once the final version of Webpack 2 is released.

[asadsahi]

@SteveSandersonMS Thanks for confirming that. Sure, in that case I think something wrong with the webpack 2 configuration somewhere which is starting the rebuild late.

Unfortunately nothing visible for me right now, which can give clue to what webpack 2 is doing after I have made the change, Random guess though, it could be DLL usage not working the way expected. Because what I have also experimented is that with or without DLL, rebuild takes same amount of time.

[asadsahi]

@sokra @TheLarkInn I think its around DLL configuration I have used with or without DLL, rebuild takes exactly same amount of time. Can you please have a look at DLL reference usage in vendor and main files

[asadsahi]

Hi guys, in desperation, I have raised same issue on stackoverflow as well, to target wider help.

Thanks

[MarkPieszak]

Did beta.24 help at all? @asadsahi

[asadsahi]

@MarkPieszak Didn't see beta.24 coming :)

Upgraded to beta 24, but its exactly same time with rebuilds.

[asadsahi]

Even webpack 2 beta.25 didn't make any difference. :(

[asadsahi]

@sokra @TheLarkInn any update on this issue? Is there a known issue with DLL plugin in webpack 2? Is there a working example we can follow for DLL in webpack 2 if it is good to use today?

[asadsahi]

Bingo!!!!!!!!!! The only reason for slow rebuilds was I changed ts-loader with awesome-typescript-loader. My goodness, tried every possible option I could to find out why rebuilds was slow. :(

Apologies, as I blamed webpack 2, .net core spa project not supporting webpack 2 perhaps etc, but both projects don't have any reason for slow rebuilds.

Now, question arose the claim made on awesome-typescript-loader repository here . Is this not valid any more or I have missed a particular option to set specifically to awesome-typescript-loader. Here are stats:

With ts-loader:

With awesome-typescript-loader:

@s-panferov any thoughts.

In case someone wants to experiment, this is my sample project. after download webpack.config.js is using ts-loader, just change to awesome-typescript-loader at this line and see the difference.

[colltoaction]

Maybe you'll have a better chance asking in their project. Would you mind
linking to here if you do so I can keep an eye on it?

On Mon, Nov 14, 2016 at 1:59 PM Asad Sahi notifications@github.com wrote:

Bingo!!!!!!!!!! The only reason for slow rebuilds was I changed ts-loader
with awesome-typescript-loader. My goodness, tried every possible option I
could to find out why rebuilds was slow. :(

Apologies, as I blamed webpack 2, .net core spa project not supporting
webpack 2 perhaps etc, but both projects don't have any reason for slow
rebuilds.

Now, question arose the claim made on awesome-typescript-loader repository here
https://github.com/s-panferov/awesome-typescript-loader. Is this not
valid any more or I have missed a particular option to set specifically to
awesome-typescript-loader. Here are stats:

With ts-loader:
[image: image]
https://cloud.githubusercontent.com/assets/3470892/20273985/1c5f2b18-aa8b-11e6-82ec-d6d1f30f498e.png

With awesome-typescript-loader:
[image: image]
https://cloud.githubusercontent.com/assets/3470892/20274107/6892a87a-aa8b-11e6-8cde-418b0baac4a8.png

@s-panferov https://github.com/s-panferov any thoughts.

In case someone wants to experiment, this
https://github.com/asadsahi/AspNetCoreSpa is my sample project.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#325 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABeg9KWs5EIdkvn3y-F8MK1elSjdjCIWks5q-JNugaJpZM4KBlAy
.

[asadsahi]

@tinchou raised an issue as you've suggested. Not sure if typescript loaders in the context of .net core is a valid use case for them or not.

[colltoaction]

there's nothing special in the compilation of the client app, it's a regular Angular application compiled using Webpack and the related loaders.