7

I have read that NodeServices have been deprecated for ASP.NET Core 3.1. Is it still possible to use Node.js to build my JavaScript files into the dist folder in wwwroot?

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
Michael Thompson
  • 83
  • 1
  • 1
  • 8
  • 2
    Hello, Michael, and welcome to Stack Overflow. I've provided a general answer below, but it'd be useful to confirm _how_ you're building your JavaScript files today. E.g., are you using **Gulp.js**, **Grunt**, or **WebPack**? Are you dynamically triggering your client-side build process via e.g. `UseWebpackDevMiddleware()`? The exact answer for your situation will depend on what build tools you're using today and how you're calling them. – Jeremy Caney Apr 02 '20 at 23:45

1 Answers1

6

According to the NodeServices package, it allows you to "invoke Node.js modules at runtime in ASP.NET Core applications" (emphasis my own). This is reiterated in more detail on the GitHub ReadMe:

This NuGet package provides a fast and robust way to invoke Node.js code from a .NET application (typically ASP.NET Core web apps). You can use this whenever you want to use Node/NPM-supplied functionality at runtime in ASP.NET.

That's entirely independent of the ability to e.g. precompile, minimize, or move JavaScript files at build time.

Build Time Tasks

You don't—and won't—need NodeServices in order to download npm package dependencies via:

  • The command prompt on your local workstation,
  • From Visual Studio's built-in integration, or
  • From a task on your build server (e.g., the npm task on Azure Pipelines).

Likewise, to precompile, minimize, and move client-side dependencies from their source directory to their distribution directory, you can (continue to?) use tools like Gulp.js, Grunt, or WebPack, which are each build systems that operate on top of Node.js.

Important: The critical distinction here is that you don't need to call these tools at runtime from your .NET application. You are incorporating the output from your Node.js build tools into your .NET application, but you aren't executing Node.js code as part of your .NET application.

The one exception to this is if you're using NodeService to dynamically perform these build tasks at runtime. For example, if your application is configured with the UseWebpackDevMiddleware() then that will no longer work. In that case, you would need to migrate to a build process that occurs prior to (or during) deployment.

Webpack

If you are using UseWebpackDevMiddleware(), then I’d recommend looking into configuring Webpack locally. That should be a pretty seamless transition. You can run it manually via the Webpack CLI, use a Visual Studio extension, or potentially even integrate it into your build process. Personally, I run it manually on my development server, then integrate it into my Azure Pipelines build process.

Alternatively, if you really want to maintain “just in time” build support for Webpack files, you can look into using the Webpack dev server in conjunction with ASP.NET Core, as discussed in Best way to integrate webpack builds with ASP.NET Core 3.0?.

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
  • Thanks Jeremy, what other build processes are there? I have been running the following via npm: webpack --mode=development However, I am getting errors in the console log of 'Failed to load resource: the server responded with a status of 404 (Not Found)' for files that would have been found with ASP.net core 2.1 – Michael Thompson Apr 03 '20 at 12:23
  • @MichaelThompson: The main Node build systems are Gulp, Grunt, and WebPack. WebPack is the simplest, so stick with that if it’s meeting your needs. If running that command from the CLI worked in .NET Core 2.1 but now fails with .NET Core 3.1, that’s independent from NodeServices, and should be posted as a new question with your configuration. As an initial troubleshooting step, though, are the JavaScript files located in the appropriate distribution folder under `wwwroot` after you run that command? That will indicate whether it’s a configuration issue with WebPack or .Net Core 3. – Jeremy Caney Apr 03 '20 at 18:39
  • 1
    Keep in mind that unless you were using `UseWebpackDevMiddleware()`, ASP.NET Core is entirely unaware of WebPack. WebPack is just automating the process of bundling, minifying, and copying your client-side files. After it runs, it’s the same as if you had manually created a file in your `wwwroot`. If WebPack is processing the files correctly, but they aren’t loading from ASP.NET Core 3.1, then it’s likely that you could manually create a file right next to its output in your `wwwroot` and that would _also_ return a 404. In that case, I’d confirm that you have `UseStaticFiles()` configured. – Jeremy Caney Apr 03 '20 at 20:47
  • Thanks this works. I have other errors in the browser console log now, but will investigate these now – Michael Thompson Apr 04 '20 at 19:57