-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: upgrade dev middleware #2660
chore: upgrade dev middleware #2660
Conversation
Codecov Report
@@ Coverage Diff @@
## v4 #2660 +/- ##
==========================================
+ Coverage 92.41% 92.53% +0.11%
==========================================
Files 34 37 +3
Lines 1292 1312 +20
Branches 357 355 -2
==========================================
+ Hits 1194 1214 +20
Misses 93 93
Partials 5 5
Continue to review full report at Codecov.
|
lib/options.json
Outdated
"type": "boolean" | ||
}, | ||
"fs": { | ||
"devMiddleware": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is good place to do discussion, should we move all webpack-dev-middleware in the one place
/cc @hiroppy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense because webpack-dev-middleware now does options validation that only allows for the properties specified. So we can just validate devMiddleware
as an object, and if the user passes in bad webpack-dev-middleware options then webpack-dev-middleware validation will throw an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer this idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's rename it to dev
, I think it is unnecessary to have middleware
suffix, we don't have it for other middlewares
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it will be better for CLI - webpack server --dev-something=value
const compiler = webpack(config); | ||
const server = new Server(compiler, baseDevConfig); | ||
|
||
server.invalidate(); | ||
expect(server.middleware.context.callbacks[0]).toBe(noop); | ||
expect(server.middleware.context.callbacks.length).toEqual(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
webpack-dev-middleware no longer exports the noop function. Should we make it get exported from webpack-dev-middleware, or do you think this is sufficient for this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's ok.
We have broken tests, maybe it is regressions, we need collect them here |
@evilebottnawi Yes, lots of broken tests because of the options changes that I still need to fix, I just wanted to confirm that you agreed with switching to |
lib/utils/normalizeOptions.js
Outdated
|
||
// this was previously done in createConfig, but it should be done | ||
// here for CLI/API uniformity | ||
if (!options.devMiddleware.publicPath) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this was a good time to move publicPath
handling from createConfig
into normalizeOptions
so it is done both on the CLI and API. Let me know if you disagree, as it is a minor breaking change for API.
EDIT: changed my mind, this can happen in a different PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's think about it in other PRs
969b1fc
to
390da6c
Compare
@Loonride Agree, let's move options to the |
I think we should remove |
All tests should be passing once webpack/webpack-dev-middleware#670 is released, then I update the webpack-dev-middleware dependency in this PR. |
@@ -62,17 +62,6 @@ const options = { | |||
describe: 'Open default browser with the specified page', | |||
requiresArg: true, | |||
}, | |||
color: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the color
CLI flag since it ends up setting colors: true
in the stats option, which was also removed.
New behavior:
- default for
colors
isfalse
(should it betrue
?) - if a user wants to turn on color, they need to put in their webpack config:
stats: { colors: true }
.
Do you think we should do this approach, or should we keep the color CLI flag and then update the compiler stats option using this flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need this option, default value is stats.colors
(https://github.com/webpack/webpack/blob/master/lib/stats/DefaultStatsPresetPlugin.js#L168), webpack-cli
should have --stats-colors
(or --colors
) flag to enable or disable it, it is out of scope webpack-dev-server
default: function supportsColor() { | ||
// Use `require('supports-color').stdout` for supports-color >= 5.0.0. | ||
// See https://github.com/webpack/webpack-dev-server/pull/1555. | ||
return require('supports-color').stdout; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not forget to remove supports-color
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// eslint-disable-next-line | ||
options.devMiddleware.publicPath = | ||
options.dev.publicPath = | ||
(firstWpOpt.output && firstWpOpt.output.publicPath) || ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is really bad idea smile But let's resolve it on the other PR
@Loonride unstable CI? |
686af31
to
3319b0b
Compare
After this PR we need to:
|
@@ -8,7 +8,7 @@ const express = require('express'); | |||
const request = require('supertest'); | |||
const testServer = require('../helpers/test-server'); | |||
const runBrowser = require('../helpers/run-browser'); | |||
const port = require('../ports-map').WebsocketClient; | |||
const port = require('../ports-map').SocketInjection; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This port was already being used which was causing some instability
@@ -4,7 +4,7 @@ const path = require('path'); | |||
const request = require('supertest'); | |||
const testServer = require('../helpers/test-server'); | |||
const config = require('../fixtures/contentbase-config/webpack.config'); | |||
const port = require('../ports-map')['contentBase-option']; | |||
const port = require('../ports-map')['contentBasePublicPath-option']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with this port
@Loonride Great! But still failed on macOS node-10-canary 😞 Very strange |
@evilebottnawi The remaining instability seems to be from puppeteer. I will look closely at that later. Does everything else look good in this PR? |
For Bugs and Features; did you add new tests?
Not yet
Motivation / Use-Case
webpack-dev-middleware needs to be updated
Take a look at the
options.json
file and tell me if these changes look good for the options.Breaking Changes
Many options being removed in favor of
devMiddleware
option.Change where
publicPath
is handled, which is minor breaking change for APIAdditional Info