Skip to content
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

Merged
merged 26 commits into from
Jul 2, 2020

Conversation

knagaitsev
Copy link
Collaborator

@knagaitsev knagaitsev commented Jun 25, 2020

  • This is a bugfix
  • This is a feature
  • This is a code refactor
  • This is a test update
  • This is a docs update
  • This is a metadata update

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 API

Additional Info

@codecov
Copy link

codecov bot commented Jun 25, 2020

Codecov Report

Merging #2660 into v4 will increase coverage by 0.11%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
lib/Server.js 95.98% <100.00%> (+0.07%) ⬆️
lib/utils/createConfig.js 95.18% <100.00%> (-0.33%) ⬇️
lib/utils/getColorsOption.js 100.00% <100.00%> (ø)
lib/utils/getCompilerConfigArray.js 100.00% <100.00%> (ø)
lib/utils/getStatsOption.js 100.00% <100.00%> (ø)
lib/utils/normalizeOptions.js 100.00% <100.00%> (ø)
lib/utils/routes.js 92.68% <100.00%> (+0.37%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb9c58d...30b3443. Read the comment docs.

lib/options.json Outdated
"type": "boolean"
},
"fs": {
"devMiddleware": {
Copy link
Member

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

Copy link
Collaborator Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer this idea.

Copy link
Member

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

Copy link
Member

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);
Copy link
Collaborator Author

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?

Copy link
Member

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.

@alexander-akait
Copy link
Member

We have broken tests, maybe it is regressions, we need collect them here

@knagaitsev
Copy link
Collaborator Author

knagaitsev commented Jun 26, 2020

@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 devMiddleware option name


// this was previously done in createConfig, but it should be done
// here for CLI/API uniformity
if (!options.devMiddleware.publicPath) {
Copy link
Collaborator Author

@knagaitsev knagaitsev Jun 28, 2020

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.

Copy link
Member

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

@knagaitsev knagaitsev force-pushed the chore/upgrade-dev-middleware branch from 969b1fc to 390da6c Compare June 28, 2020 16:55
@alexander-akait
Copy link
Member

@Loonride Agree, let's move options to the dev object

@alexander-akait
Copy link
Member

alexander-akait commented Jun 29, 2020

I think we should remove stats option from webpack-dev-server because new version of webpack-dev-middleware take value from configuration, so you don't need it anymore, if you want to change it you can use stats: WEBPACK_DEV_SERVER ? 'warnings-errors' : 'verbose'

@knagaitsev
Copy link
Collaborator Author

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: {
Copy link
Collaborator Author

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 is false (should it be true?)
  • 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?

Copy link
Member

@alexander-akait alexander-akait Jun 30, 2020

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;
Copy link
Member

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

Copy link
Collaborator Author

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) || '';
Copy link
Member

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

@alexander-akait
Copy link
Member

@Loonride unstable CI?

@knagaitsev knagaitsev force-pushed the chore/upgrade-dev-middleware branch from 686af31 to 3319b0b Compare July 1, 2020 18:39
@knagaitsev
Copy link
Collaborator Author

knagaitsev commented Jul 1, 2020

After this PR we need to:

  • Change how publicPath is handled
  • Look deeper into test instability (puppeteer)
  • Create checks to ensure ports are not reused from the testing ports map
  • Investigate why webpack compilation calls the done hook many times if the compiler starts directly after an fs.writeFileSync of a CSS file in the compilation (it works fine if there is a 1 second delay between file writing and compilation start)

@@ -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;
Copy link
Collaborator Author

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'];
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same with this port

@alexander-akait
Copy link
Member

@Loonride Great! But still failed on macOS node-10-canary 😞 Very strange

@knagaitsev
Copy link
Collaborator Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants