You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
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?
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.
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:
however, this would likely be a breaking change so you might want to check for the presence of compiler.hooks
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?
Reacted by Lars Kjær Thomsen, Nordes Ménard-Lamarre, Chad Carter, Florian Bacher and Ben Rubinger
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.
Reacted by Brian Harney, Chris Tracy, Olof Dahlbom, Max Melcher, bastienJS and Leonardo Carreiro
@JohnGalt1717 I was able to resolve the my HMR issue by switching from awesome-typescript-loader to ts-loader@4.1.0. 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.
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)
@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 aspnet-webpack@3.0.0 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.
Activity
mattvperry commentedon Mar 7, 2018
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?
lkt82 commentedon Mar 8, 2018
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: [
]
}
mattvperry commentedon Mar 8, 2018
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.
mattvperry commentedon Mar 10, 2018
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
.pluginapi on the webpack compiler object is deprecated in favor of the.hooksapi.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:
should be
however, this would likely be a breaking change so you might want to check for the presence of
compiler.hooksaspnet-webpackdepends on a old version ofwebpack-dev-middlewareand that version still uses the.pluginapi. 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 movingwebpack-dev-middlewareto a peerDependency and then provided documentation for choosing the correct version?JohnGalt1717 commentedon Mar 14, 2018
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.
mattvperry commentedon Mar 28, 2018
@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.
bharney commentedon Mar 29, 2018
@JohnGalt1717 I was able to resolve the my HMR issue by switching from
awesome-typescript-loadertots-loader@4.1.0. 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.olofd commentedon Apr 3, 2018
I get this after updating to Webpack 4.
Module not found: Error: Can't resolve 'react-hot-loader/webpackIs it from here:
JavaScriptServices/src/Microsoft.AspNetCore.SpaServices/npm/aspnet-webpack-react/src/HotModuleReplacement.ts
Line 3 in 48b923f
?
Guymestef commentedon Apr 3, 2018
@olofd it's not an issue with webpack 4 but with react-hot-loader v4, an issue has already been submitted #1585
pheuter commentedon Apr 14, 2018
According to my app logs below, it seems like the main issue is that the latest version of
aspnet-webpackdepends on an older version ofwebpack-dev-middleware, 1.8.4 to be exact. The latest version is 3.1.2 and likely includes support for webpack v4.mattvperry commentedon Apr 14, 2018
@pheuter yes, webpack-dev-middleware is the main source of the issue. See my PR here:
#1606
SteveSandersonMS commentedon May 29, 2018
We just published
aspnet-webpackwith @mattvperry's fixes for Webpack 4 compatibility.pfbristow commentedon Jun 2, 2018
@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 aspnet-webpack@3.0.0 requires a peer of webpack-dev-middleware@^1.8.4 || ^3.0.0 but none is installed. You must install peer dependencies yourself.mattvperry commentedon Jun 2, 2018
@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.