Consider a different way for hot module replacement about javascriptservices HOT 6 CLOSED

Thanks for letting me know about aspnet-webpack! If this is able to provide at least as much functionality as the existing Webpack middleware mechanism and has other advantages then I'd definitely be interested in switching to it.

Can you clarify what the benefits of aspnet-webpack are?

the middleware intercepts the request and adds the appropriate script tag on the html page so the developer doesn't have to do that as well

OK I think I follow. The Webpack middleware I've been putting in these template avoids the need to change your HTML at all by intercepting the requests for Webpack-built content and serving them using the middleware. TBH this sounds more straightforward for the developer as it's exactly the same as if you were serving pre-built files from disk (just that you don't need to have pre-built them) but please let me know if I'm missing the benefits.

from javascriptservices.

Yes you understood correctly Steve. What the aspnet-weback does in that intercepts the requests and changes the html by adding a script tag to the bundle that lives in the webpack-dev-server. In this case I am using the functionality of webpack-dev-server to just serve and update all the static resources.

I would say I tried to give a wider solution on how to use webpack with aspnet core. For the simple scenarios you don't have to write any webpack configuration file as I am using the cli with the appropriate arguments so it's easier for the developer to start with. All the configuration is in C# code and you have just to install the correct node modules, something that maybe could change. On top of that you can use aspnet-webpack for handling all static resources. In general I really believe that all the static resources (js, styles, images, fonts) should be handled with webpack and not through bower and gulp as the current templates of aspnet core applications doing.

from javascriptservices.

Cool - thanks for the info. If a good scenario for using aspnet-webpack comes up then I'd definitely be happy to look into using it. For the templates I'm working on at the moment, we certainly need webpack config files (as there are loads of possible ways you might want to configure things, and any number of third-party webpack loaders and plugins you might want to bring in).

I'll close this now as it seems like there isn't anything to do in the short term, but please let me know if you think there is.

from javascriptservices.

Just to mention I also created https://github.com/frankwallis/WebpackAspnetMiddleware which provides development middleware and hot reload support. It uses the standard webpack configuration file.

It uses NodeServices to manage the nodejs instance, but has its own nodejs host which uses a persistent socket connection for two-way communication between webpack and the asp.net server.

from javascriptservices.

Yes I am aware of your project too and I think is a nice effort. I tried to go a different route and use command line arguments as much as possible instead of configuration file to make the usage of webpack easier for the final developer. Especially in the early steps and for the most common scenarios.

from javascriptservices.

Yes I took the view that all the configuration should remain in the webpack config file as that is what will be used when the app is being bundled for production and on the CI server. It also means there is less work to document your own configuration API and to keep up to date with any changes to the webpack API, I think that is important in these kind of 'adapter' projects. Your way may well be easier to get up and running with though, it's horses for courses I suppose.

from javascriptservices.