Description
Hi:) I'm getting an error when I try to use webpack 4 in combination with UseWebpackDevMiddleware
Error Message
fail: Microsoft.AspNetCore.NodeServices[0]
(node:19264) DeprecationWarning: Tapable.plugin is deprecated. Use new API on .hooks instead
Is this something you can fix :)?
The error @lkt82 is experiencing is likely coming from their webpack.config. There are several webpack plugins that haven't updated to webpack 4's new APIs.
However, this repo does need to do some work to enable webpack 4 support. A couple things I noticed from my own tests:
webpack requires that you set a mode now for builds (either 'production' or 'development'). You can work around this by setting the mode in your actual config. I do this through the --env.prod flag that the templates here recommended.
It seems that your HMR injection in aspnet-webpack isn't working properly with webpack 4. I haven't looked into this much but it might have something to do with how you are initializing the dev server?
I am not using any plugins at all.
{
entry: { main: "./server.tsx" },
resolve: {
extensions: [".js", ".ts", ".tsx"]
},
output: {
path: dst,
filename: "server.js",
publicPath: "/",
library: "server",
libraryTarget: "umd",
umdNamedDefine: true
},
module: {
rules: [
{
test: /.tsx?$/,
exclude: /(node_modules|bower_components)/,
loader: "ts-loader",
options: { compilerOptions: { "noEmit": false } }
}
]
},
mode: "development",
target: "node",
plugins: [
]
}
Its possible that ts-loader is causing your deprecation warning. However, it is also entirely possible that this repo's aspnet-webpack is causing it too. I am not sure. But at least for now, that deprecation warning should not be blocking anything.
I've done a little more investigation into this:
The aspnet-webpack package can work as-is with webpack 4 but you will get those deprecation warnings because the .plugin api on the webpack compiler object is deprecated in favor of the .hooks api.
The deprecation warning will only show up once even if multiple places are using the old api meaning it takes a bit of time to find all the causes of it. I have identified two so far:
1) In WebpackDevMiddleware.ts, this code:
(compiler as any).plugin('done', stats => {
copyRecursiveToRealFsSync(compiler.outputFileSystem, '/', [/\.hot-update\.(js|json|js\.map)$/]);
});
should be
(compiler as any).hooks.done('aspnet-webpack', stats => {
copyRecursiveToRealFsSync(compiler.outputFileSystem, '/', [/\.hot-update\.(js|json|js\.map)$/]);
});
however, this would likely be a breaking change so you might want to check for the presence of compiler.hooks
2) aspnet-webpack depends on a old version of webpack-dev-middleware and that version still uses the .plugin api. This would need to be upgraded to the latest version, however this would also be a breaking change. I don't know the right answer here. Possibly moving webpack-dev-middleware to a peerDependency and then provided documentation for choosing the correct version?
On HMR, it seems to be working but for several versions now it has been kicking off a full rebuild on startup which is maddening.
Also when it does HMR it is rebuilding all entrypoints not just the one that changed so all of my vendor and polyfills are getting rebuilt for no reason.
Would love to be able to specify the entrypoint that it monitors for rebuilds.
@SteveSandersonMS Is this something that is on your radar or something you'd accept a PR for? I was initially hesitant to make a PR for this because it'd likely be breaking and didn't want to mess with your support story.
@JohnGalt1717 I was able to resolve the my HMR issue by switching from awesome-typescript-loader to [email protected]. Since upgrading to Webpack 4, I had not been able to get HMR to properly update without a NodeServices error. The switch to ts-loader was trivia. Hopefully you are able to resolve your issue.
I get this after updating to Webpack 4.
Module not found: Error: Can't resolve 'react-hot-loader/webpack
?
@olofd it's not an issue with webpack 4 but with react-hot-loader v4, an issue has already been submitted #1585
According to my app logs below, it seems like the main issue is that the latest version of aspnet-webpack depends on an older version of webpack-dev-middleware, 1.8.4 to be exact. The latest version is 3.1.2 and likely includes support for webpack v4.
fail: Microsoft.AspNetCore.NodeServices[0]
app_1 | (node:124) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
app_1 | at Shared (/app/node_modules/webpack-dev-middleware/lib/Shared.js:233:19)
app_1 | at module.exports (/app/node_modules/webpack-dev-middleware/middleware.js:22:15)
app_1 | at attachWebpackDevMiddleware (/app/node_modules/aspnet-webpack/WebpackDevMiddleware.js:72:46)
app_1 | at /app/node_modules/aspnet-webpack/WebpackDevMiddleware.js:266:25
app_1 | at Array.forEach (<anonymous>)
app_1 | at Server.<anonymous> (/app/node_modules/aspnet-webpack/WebpackDevMiddleware.js:229:36)
app_1 | at Object.onceWrapper (events.js:313:30)
app_1 | at emitNone (events.js:106:13)
app_1 | at Server.emit (events.js:208:7)
app_1 | at emitListeningNT (net.js:1378:10)
@pheuter yes, webpack-dev-middleware is the main source of the issue. See my PR here:
We just published aspnet-webpack with @mattvperry's fixes for Webpack 4 compatibility.
@SteveSandersonMS Is aspnet-webpack supposed to be compatible with webpack 4? I'm seeing the following npm warning below. I'm also running into problems, but that might be irrelevant if support for webpack 4 is still a work in progress.
npm WARN [email protected] requires a peer of webpack-dev-middleware@^1.8.4 || ^3.0.0 but none is installed. You must install peer dependencies yourself.
@pbarranis you need to follow the instructions in the npm warning. webpack-dev-middleware is now a peer dependency so that aspnet-webpack stays backwards compatible with older webpack versions. If you are using webpack 4 then you'll need to add the latest webpack-dev-middleware to your project's dev-dependencies as well.
Most helpful comment
@SteveSandersonMS Is this something that is on your radar or something you'd accept a PR for? I was initially hesitant to make a PR for this because it'd likely be breaking and didn't want to mess with your support story.