Slow rebuilds after upgrading to webpack 2.1.0-beta.23

@SteveSandersonMS

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.

@sokra

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

@TheLarkInn

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(); });
}

@TheLarkInn

@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.

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.

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!

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

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

@sokra

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

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

@SteveSandersonMS

@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:

no empty extension available in webpack 2 now so extensions: ['.js', '.ts'],
Change of loaders > rules property in webpack module configuration
Addition of SCSS loader
changing ts-loader with awesome-typescript-loader
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.
Some peer dependencies of webpack 2 upgrade as well.
Changing require('') > imports in polyfills.ts
Removed server rendering with Universal

@sokra

@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).

As per #325, reference module.hot directly instead of via a local var…

@SteveSandersonMS

@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?

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.

@SteveSandersonMS

@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.

@sokra

@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

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

Thanks

@asadsahi

Did beta.24 help at all? @asadsahi

@MarkPieszak

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

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

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

@sokra

@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?

@s-panferov

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.

@s-panferov

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
.

@tinchou

@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.

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

Navigation Menu

Repository navigation

Slow rebuilds after upgrading to webpack 2.1.0-beta.23 #325

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Slow rebuilds after upgrading to webpack 2.1.0-beta.23 #325

Description

Activity

TheLarkInn commented on Sep 20, 2016

MarkPieszak commented on Sep 20, 2016

asadsahi commented on Sep 20, 2016

SteveSandersonMS commented on Sep 20, 2016

SteveSandersonMS commented on Sep 20, 2016

sokra commented on Sep 20, 2016

SteveSandersonMS commented on Sep 20, 2016

sokra commented on Sep 20, 2016

asadsahi commented on Sep 20, 2016

SteveSandersonMS commented on Sep 20, 2016

asadsahi commented on Sep 20, 2016

SteveSandersonMS commented on Sep 20, 2016

asadsahi commented on Sep 20, 2016

asadsahi commented on Sep 20, 2016

asadsahi commented on Sep 21, 2016

MarkPieszak commented on Sep 21, 2016

asadsahi commented on Sep 21, 2016

asadsahi commented on Sep 22, 2016

asadsahi commented on Oct 27, 2016

asadsahi commented on Nov 14, 2016

colltoaction commented on Nov 14, 2016

asadsahi commented on Nov 14, 2016

colltoaction commented on Nov 14, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions