I’m using the latest sage@9.0.0-alpha.3 and when I’m working on js files after saving it I can’t see any different behavior.
I have to stop the npm start command and then run it again.
I’m on Windows 10, anyone has been able to resolve it?
Hey can you share with me how do you create-project using your fork? I’m lost using composer.
My fork is not available on packagist as it’s not meant to be pulled in for your projects. It’s my testing ground, with lots of personal configurations and such things. I published it just to share the way I organized my package.json and my assets/build structure, hoping to help whoever is struggling with the performances from webpack2, until a better solution comes out.
Feel free to browse my fork and grab what you need but don’t pull it into your project as it is as it will high-likely give you more troubles than benefits 
Also, regarding your issue with your js assets, depending on how you’re developing, you might just have to refresh your browser, without having to restart browsersync. You can also add your .js assets to the browsersync files section to trigger an automatic reload.
@Nicolo_Sacchi Using Webpack 2 and doing some experimenting with Source Maps I’ve got slow initial builds (which I don’t care about) and then incremental builds are down around 1000ms which is fast enough to not annoy me.
This suits me for now doing a lot of markup + sass. But when my project gets more JS heavy I might revisit.
I edited the following:
https://github.com/roots/sage/blob/master/assets/build/webpack.config.js#L38
devtool: (config.enabled.sourceMaps ? '#source-map' : undefined),
to
devtool: (config.enabled.sourceMaps ? '#eval' : undefined),
as well as the edit here:
as well as changing 2x this:
stats: {colors: true}
to
stats: { colors: true, hash: false, version: false, timings: false, assets: false, chunks: false, modules: false, reasons: false, children: false, source: false, errors: false, errorDetails: false, warnings: false, publicPath: false },
1 Like
Thanks for the info @ian!
I’m currently waiting as I don’t want to work with an outdated version of webpack@2 and the latest beta has a bug when processing the entrypoints list.
The bug has been signaled and they’re currently working on it see here.
I already updated my webpack.config files to work with the latest realease but I’ll wait until this bug has been fixed. I’ll keep in mind your solution although I had a feeling it would be better to start browsersync by itself and just inject the webpack-dev-middleware there more than waiting for webpack to complete the build and pass it on to browsersync! Hopefully I’ll have more time to test this in a few weeks!
Thanks for your reply. I’ve tried every possible way to make it reload but it just doesn’t work. The only way I can get my js code reloaded is to stop Webpack and run it again. And this just takes too much time
So for my clients I’ve decided to use the stable version of Sage because this would be disaster 
With webpack 2.1.0-beta.22, trying @ian’s suggestions, I still get 5.4 second rebuilds using a fresh Sage 9 alpha-3 install. That’s way too long.
Thank’s for all the work @ian, are you still using Fusion with the various network tweaks to keep performance at this level?
With webpack@2.1.0-beta.27 and the latest version of sage (alpha-4) slightly tweaked, I have incremental builds around 400msec. Full build is between 15 sec which I don’t mind since it’s handled in the CI system.
What tweaks did you make?
Feel free to submit a PR if you want.
Nothing major to be honest!
I decided to stick with babel more than buble for the js part.
Added a couple of other configurations that are outside of the sage scope (modernizr, vuejs, videojs and some google libs).
I can submit a PR if you like but it’s really nothing major. It’s more of a personal preference (I’m more across babel so I feel like I can tweak it more if I need, but I haven’t spent much time looking into buble honestly!)
I’m just trying to figure out how you got it so that scss builds in 400ms. Did you remove all of the Bootstrap @import statements or something?
Yes I have a custom bootstrap loader so that I can only include the components I need, plus I code-splitted everything within my project, so that everything gets compiled as a standalone component.
But this is more something related to the project design more than sage itself. It might be good to give an example to show how to organise it. I can create an example repo if you want so that I can share with you my current setup.
1 Like
Would be interested in seeing this for sure. Are you using https://github.com/shakacode/bootstrap-loader?
Would love to see an example repo so maybe we can learn some things from it! Thanks
Hey guys, I just installed all the latest and greatest, and I’m getting 4-5 second rebuilds—I’m guessing this still really hasn’t been fixed? Or did I miss something? I removed sourcemaps and moved css-loader to 0.14, so now I’m getting 2s rebuilds, but less than 1s would be ideal.
Is @Nicolo_Sacchi’s fork the only way around this for now?
@ben What’s the current status regarding this? I would love to be able to load only specific bootstrap components.
Did you maybe try to implement https://github.com/shakacode/bootstrap-loader? to Sage 9?
Pardon me, I’ve been super buys at work lately. I’ll try to create an example repo this weekend!
1 Like
any news over here?
i moved back to grunt, as i was having 6s-10s waiting between style injections. php reloads were worse as it only loaded partially but i didn’t implement the linter stuff.
I never got around creating the example repo, apologies about that! I got pretty busy this year.
Either way, with the latest release of sage/webpack, the compile times are down to a few milliseconds for me so I feel like this post is pretty irrelevant. The longest I’ve to wait is around 2~3 secs for the styles when I push pretty big changes which is the same I was waiting with gulp/previous versions of webpack. The cache-loader module of webpack does an amazing job and speeding up builds!
1 Like