Please Upgrade to Core 3 #138
Comments
|
+1, We are also experiencing this issue |
|
Core 3 has removed HMR. |
|
So there is no workaround? |
|
Not at this time, I believe Microsoft is expecting the community to pick up these packages. Very frustrating, if you ask me. |
|
|
Even if UseWebpackDevMiddleware is obsolate today, not deprecated, it doesn't work. I upgraded to 3.0, and the __webpack_hmr endpoint does nothing. No updates, nor heartbeats. Sad :( Staying at .net core 2.2. |
|
@Grandizer , @kiran94 , @JoshDiDuca , @poganytamastsys |
|
@UseMuse This is a great start having HMR back. My only concern is that instead of using chunks, it rebuilds the whole main.js, therefore reloading the whole page. |
No, you didn't. WestWind.AspNetCore.LiveReload reloads the entire page whenever any single file it monitors is changed. That is cold reloading, not hot reloading in the normal sense of module replacement within a running page. |
|
Is there any progress? @MarkPieszak |
|
(Updated 20191229) I converted my 2.2 project based on this template to 3.1. It took about two days of toiling, so I'm posting what I did for possible benefit to others. It does not have hot or cold reloading, but the package.json has been modified to always rebuild the files in the wwwroot/dist folder on project build. Sorry about the formatting of the code sections - I could not get it to work as desired.
This requires numerous changes to startup.cs. As others have noted, the hot reloading is deleted from the new DLLs. `using Microsoft.AspNetCore.Builder; namespace Vue2Spa }` Program.cs namespace Vue2Spa }`
For some unexplainable reason a section is being shown as code, you'll need to decode it with and online html decoder to show the < and > characters correctly. <Project Sdk="Microsoft.NET.Sdk.Web"> <ItemGroup> <ItemGroup> <Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') "> <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish"> </Target> </Project>
Delete Delete Update rule for css
const MiniCssExtractPlugin = require('mini-css-extract-plugin'); module.exports = () => {
6, (Optional) Update to use FontAwesome 5. b. Install the latest npm packages c. Modify icons.js to use the new standards. The code sample shows individual icons being added. The new version has a tree-shaking feature which I didn't fully understand, but may allow you to just link to the library. //These commands import libraries. It is not known if "tree-shaking" will remove the unused icons so that only used icons are included //The following commands import specific icons library.add(faFontAwesome, faMicrosoft, faVuejs) import { faHome } from '@fortawesome/free-solid-svg-icons/faHome' library.add(faHome, faList, faGraduationCap, faSpinner, faExclamationTriangle, faCog, faCheckSquare, faTimesCircle, faCheck, faAngleUp ) export {
{
For manual rebuilding: At a powershell command prompt at the root of the project, Run the following to update main.js and main.js.map |
|
Actually, there's a way to make the hot-reload works. It require to use the I did it on my current VueJS starter (different repository than this using picnic css instead of bootstrap). However, it requires you normally to start the VueJS project using WebPack outside of Visual Studio using let's say In order to avoid running the webpack-dev-server everytime, you could lazilly start a BackgroundService in C#. The caveat with that is that if you push the Stop/Restart button in the IDE it kills the C# application, but does not terminate properly the sub-process tree (current bug: dotnet/aspnetcore#5204). If you use the update: Issue dotnet/aspnetcore#5204 was fixed today 31st of jan. 2020 🎉 |
|
+1 I'm also looking to use this template but keen to start from a net core 3.0/3.1 base. |
|
@Nordes the problem with that approach is to completely leave the MVC Razor pages completely. Which I wouldn't agree with. With SPA, trying to handle requests and things over the network is WAY more complex than it needs to be, and that complexity grows quickly. Some people won't be up for that. When using MVC views, I have very simple configs to handle auths, and there are nice Authorize decorators I use to wrap each view, to go completely JS in that manner would be a huge pain for me and other devs who wants to have nicer options of turning it off. However, I do agree with you that developing a SPA is very easy, and it includes hot-reloading. In my case, I derailed a bit away from this GitHub project's template. First, I began using Vue-CLI as it abstracts away a lot of Vue stuff from webpack. In fact, I favor this approach than straight-up using webpack because the Vue-CLI config brings in a lot of things to aid in your Vue development that you would have had to otherwise set up in your webpack. Take a look at a vue.config.js file and compare that to what you see in webpack.config.js setting up Vue, you'll know straight away which is simpler. Vue-CLI creates a lot of files that you'd need to set up a location for. In order to get what I had working with Razor, I needed to create two separate environments in launchSettings. One is to use the Vue-CLI dev server - without controllers, and the other is to use IIS Express with controllers set up. It was a bit messy because I took the generated index.html that Vue-cli created (it brings in the js and CSS that Vue-CLI bundled and compiled). I converted it into a string, sanitized it as much as I could, and then dumped it into my index.cshtml. When I have time, I'll take the template from this github project, and convert it the same way I did with my project, and I'll add it to my github repo. |
|
Any news upgrading this template to 3.x with hmr? |
|
I've been trying to get HMR working in our .Net Core 3.1+Vue project that was based on an earlier version of this starter template. It would appear that UseWebpackDevMiddleware isn't gone, it's just moved into the Microsoft.AspNetCore.SpaServices.Extensions nuget package. I downloaded the current code, added that package, added "options => options.EnableEndpointRouting = false" to the services.AddMvc constructor in Startup.cs, updated the project to 3.1 and everything compiled. Any changes I make appear to trigger webpack to recompile. The only thing that doesn't seem to work is that the browser doesn't automatically refresh but if I refresh manually I see the changes. I'm going to try and see if that's fixable but even so it's better than a full recompile of our .NET project. |
|
You can use my forked repo if you want. It works on ASP Core 3.1. It's a bit hacky because I glued the VUE-CLI to MVC. You can see how hacky it is when you see that I basically did a straight-up html injection of the generated index.html outputted by VUE-CLI into an MVC view cshtml file. Because I'm using VUE-CLI, there are no webpack dependencies. And yes, hot-reload works using the VUE-CLI dev server. I tried my best to give instructions on how it works and how to configure it to your liking because I wanted it to be as flexible as possible. It is also being used in my client's production environment. If you want, you could turn off ever using MVC, meaning no controllers or views. I needed it as the project I was working on had server-side security features I needed to implement. I should probably break up the code to reflect that, how to have it work with MVC and how to make it work just by using the VUE-CLI |
|
I happened to drop by parachute here when I was trying to find an easier way for the aspnet-core to run JS code "directly", iow, I want to call functions in JS, and needed some kind of bi-directional interop layer. I guess I'm going to keep using 2 Webpacks, one to server-side render, and the other to client-side render, and some unwieldy bunch of crap code that taps into Webpack's internals and do some shenanigans. You can control both "instances" of webpack running in the same node, and do some hacks when they are running.
Click to expand!const path = require('path');
const webpack = require('webpack');
const Module = require('module');
const fs = require('fs');
const outputStats = (logger, err, stats) => {
if (err) {
logger.error(err)
return true;
}
const info = stats.toJson('verbose');
(info.errors || []).forEach(logger.error.bind(logger));
(info.warnings || []).forEach(logger.warn.bind(logger));
logger.log(stats.toString({
colors: true
}));
return false;
};
const parentModule = module;
const exec = (code, loaderContext) => {
const { resource, context } = loaderContext;
const module = new Module(resource, parentModule);
module.paths = Module._nodeModulePaths(context);
module.filename = resource;
module._compile(code, resource);
return module.exports;
}
module.exports = (options, loaderContext) => {
const logger = loaderContext.getLogger('SSR')
return new Promise((resolve, reject) => {
logger.log('SSR: Compiling ...');
const configSSR = path.join(__dirname, options.config);
loaderContext.addDependency(configSSR);
const webpackConf = require(configSSR);
const finalConf = webpackConf(options.baseConfig());
const outputPath = finalConf.output.path;
const serverCompiler = webpack(finalConf);
serverCompiler.run((err, stats) => {
if (outputStats(logger, err, stats)) {
reject(new Error('Webpack failed.'));
return;
}
const assets = stats.compilation.assets;
const fileDeps = stats.compilation.fileDependencies;
const ctxDeps = stats.compilation.contextDependencies;
const entry = stats.compilation.entrypoints.keys().next().value;
const asset = Object.keys(assets).reduce((_, a) => a.startsWith(entry) ? a : null);
fs.readFile(path.join(outputPath, asset), (err, content) => {
if (err) {
reject(new Error(`Webpack couldn\'t find the "${asset}" file.`));
return;
}
let modl;
try {
modl = exec(content.toString('utf8'), loaderContext);
} catch (err) {
reject(new Error(`Failure compiling "${entry}": ${err}`));
return;
}
let output;
try {
output = modl[Object.keys(modl)[0]]();
} catch (err) {
reject(new Error(`Failure running "${entry}": ${err}`))
return;
}
const emitFile = files => {
if (!files || !files[0]) {
resolve({
code: output,
dependencies: fileDeps,
contextDependencies: ctxDeps,
cacheable: true,
})
logger.log('SSR: Done');
return;
}
const file = files[0];
fs.readFile(path.join(outputPath, file), (err, content) => {
loaderContext.emitFile(file, content);
if (err) {
reject(new Error(`Webpack couldn\'t find the "${file}" file.`));
return;
}
emitFile(files.splice(1));
});
};
const extras = Object.keys(assets).filter((a) => !a.startsWith(entry));
emitFile(extras);
});
});
});
};The only thing that saved me the effort of having to fix this crap was https://fable.io/ I was just doing this experiment on getting rid of webpack, I guess I won't then. At least Blazor is supposed to implement packing and bundling, then all they need to actually do, if they are that committed to support Blazor is to write something that converts Javascript to C#, this would be immensely useful. I'm not going to migrate to Blazer for that, heck, I'll write my own webpacker in F#, its easier. |
|
Found this https://github.com/Taritsyn/JavaScriptEngineSwitcher/ |
I am attempting to upgrade my app to Core 3 and am running into this issue.
The text was updated successfully, but these errors were encountered: