Do I win an award for the longest, most boring blog title in the world?
I’ve been doing some work with Angular recently, using Steve Sanderson’s excellent templates for ASP.NET Core.
It’s been interesting, since I’m not a client-side type, so a lot of the ceremony involved is a little alien to me. That mostly means that when things go wrong, it’s a bit harder to diagnose where I’ve made a mistake, but I’ve been doing OK.
Where I’ve been really struggling, for several days now, is in trying to update the Angular package versions I’ve been using.
In my innocence, I had wondered if all I needed to do was change the version numbers in the package.json to the new version. I needed to bump up the minor version to take advantage of improvements in the animation APIs.
But this naive approach left me with an application that was just broken, but broken in a way that gave almost no clue as to the reason.
Exception: Call to Node module failed with error: Prerendering failed because of error: TypeError: Object prototype may only be an Object or null: undefined at setPrototypeOf (native)
This is about the most generic, information-free error you could imagine. Even with the associated stack trace, I didn’t have a clue what it meant, nor how to track it down.
But I did, just now, discover what I think is the core reason why the build was failing.
The reason is that the template does some clever stuff under the hood, to enable hot module replacement as you’re developing, but if node modules change, that’s not enough, and the key part of the build isn’t happening – webpack isn’t packaging up the code again.
I seem to have fixed the build by invoking webpack by hand using the following two commands:
webpack --config webpack.config.vendor.js
- and then
This rebuilds the files that contain the code for the site, in the dist folder in ClientApp and wwwroot. They’re also not tracked by source control, so they can end up missing if you’re cloning a repo.
Important safety tip: If you’re updating version numbers in Package.json, either do it with the solution closed, or let Visual Studio run the npm install. I’ve made the mistake of editing the packages, then trying to npm install from the command line, and that means there’s two installs happening, and they end up fighting with each other.
I still don’t know why these webpack rebuilds weren’t happening with the default setup of the project. I’m assuming it’s only something that should happen when packages update, but it does have the nasty effect of leaving your project badly broken, such that even if you revert the package version changes, often your dist files are still really broken.