-
-
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
feat: remove CLI progress and move progress option into client #2857
Conversation
Codecov Report
@@ Coverage Diff @@
## v4 #2857 +/- ##
==========================================
- Coverage 92.62% 92.61% -0.01%
==========================================
Files 38 38
Lines 1247 1246 -1
Branches 326 326
==========================================
- Hits 1155 1154 -1
Misses 87 87
Partials 5 5
Continue to review full report at Codecov.
|
And other simple breaking change:
I apologize very much for that, I haven't looked into the code for many times and want to reduce complex as much as possible (especial unnecessary options, lets options === better DX) and progress should be moved in |
Aren't |
lib/options.json
Outdated
@@ -292,11 +292,15 @@ | |||
} | |||
] | |||
}, | |||
"profile": { | |||
"type": "boolean" | |||
}, | |||
"progress": { |
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 move progress
to client
object, because we use progress plugin only for client
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 seems it's also used for the CLI output and profile
is only used for it:
webpack-dev-server/lib/Server.js
Lines 86 to 91 in 9020c23
// for CLI output | |
new webpack.ProgressPlugin({ | |
profile: this.options.progress === 'profile', | |
}).apply(this.compiler); | |
// for browser console output |
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.
Aren't progress and profile for the webpack compilation?
For us no, we just emit them to client using sockets
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.
oh, we should remove this, this plugin is unnecessary, webpack serve --progress
should enable this plugin on webpack-cli
side (like just run webpack --progress
), I think it is already works like this, but we need to test it, adding progress plugin is out of scope webpack-dev-server, also if somebody already use this plugin in this configuration we will adding plugin twice
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.
Should we add I'll move clientProgress
or consoleProgress
, or would it be too much?progress
to client
and remove profile
.
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.
Can we add tests for cli too to ensure --progress
works fine via CLI for node (for browser I think we already have tests)
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.
Like webpack serve --progress
and look at output
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 cannot find a way to mock stderr
with TTY support. I've tried wrapping process.stderr
and passing stderr: 'inherit'
to execa
, but it doesn't work.
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.
Why we need mock here? Why just do not run execa
and get stderr
?
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 it was TTY issue why it didn't print the progress. However, it seems @webpack-cli/serve
doesn't add WebpackCLIPlugin
, i.e., doesn't call cli.run()
(https://github.com/webpack/webpack-cli/blob/2cd4f1f5d4e99fe5b825d1105e5babe292d99c63/packages/webpack-cli/lib/webpack-cli.js#L595-L597), which is responsible for adding the progress plugin.
@@ -106,7 +115,6 @@ module.exports = { | |||
describe: 'Enable gzip compression', | |||
group: RESPONSE_GROUP, | |||
}, | |||
// findPort is currently not set up |
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.
why did you comment out?
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.
The TODO was resolved in #2845.
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.
@ylemkimon Can we remove this?
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.
@evilebottnawi Do you mean removing port
from options
?
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.
Oh, my mistake, all is fine
@ylemkimon @hiroppy Today I want to release
I want to hold What do you think? |
yes, me too. Not your fault we have many breaking changes so |
Release beta to collect actual usage status, in my local, it's looking good, but can't represent everyone, if release beta I will migrate as soon as possible |
⭐ I need some improvements on CLI side ( |
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.
/cc @hiroppy
@ylemkimon My idea right now - move |
if (this.options.progress) { | ||
this.sockWrite([connection], 'progress', this.options.progress); | ||
if (this.options.client.progress) { | ||
this.sockWrite([connection], 'progress', this.options.client.progress); | ||
} | ||
|
||
if (this.options.clientOverlay) { |
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 just realized this should be this.options.client.overlay
.
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 fix it in the separate PR
What do you think about:
|
@ylemkimon I need think about it, let's focus on |
Should I open a new PR for |
@ylemkimon New PR |
Let's merge this |
For Bugs and Features; did you add new tests?
Yes
Motivation / Use-Case
bin/options.js
in favor ofbin/cli-flags.js
.profile
optionprogress
option toclient.progress
and added--client-progress
.Breaking Changes
bin/options.js
is removed.profile
(--profile
) option is removed, to print profile data, setprogress: 'profile'
(--progress profile
).progress
(--progress
) option is moved toclient
, setclient: {progress: true}
(--client-progress
).Additional Info
Depends on webpack/webpack-cli#2133.