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

feat: remove CLI progress and move progress option into client #2857

Merged
merged 5 commits into from
Nov 26, 2020

Conversation

ylemkimon
Copy link
Contributor

@ylemkimon ylemkimon commented Nov 24, 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?

Yes

Motivation / Use-Case

  • Remove unused bin/options.js in favor of bin/cli-flags.js.
  • Removed CLI progress output and profile option
  • Moved progress option to client.progress and added --client-progress.

Breaking Changes

  • bin/options.js is removed.
  • profile (--profile) option is removed, to print profile data, set progress: 'profile' (--progress profile).
  • progress (--progress) option is moved to client, set client: {progress: true} (--client-progress).

Additional Info

Depends on webpack/webpack-cli#2133.

@codecov
Copy link

codecov bot commented Nov 24, 2020

Codecov Report

Merging #2857 (0c89036) into v4 (ccdce35) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
lib/Server.js 95.46% <100.00%> (-0.02%) ⬇️

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 ccdce35...0c89036. Read the comment docs.

@alexander-akait
Copy link
Member

alexander-akait commented Nov 24, 2020

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 client options, because it is only for client

@ylemkimon ylemkimon changed the title fix: remove unused bin/options.js feat(options): merge profile option into progress Nov 24, 2020
@ylemkimon
Copy link
Contributor Author

and progress should be moved in client options, because it is only for client

Aren't progress and profile for the webpack compilation?

lib/options.json Outdated
@@ -292,11 +292,15 @@
}
]
},
"profile": {
"type": "boolean"
},
"progress": {
Copy link
Member

@alexander-akait alexander-akait Nov 24, 2020

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

Copy link
Contributor Author

@ylemkimon ylemkimon Nov 24, 2020

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:

// for CLI output
new webpack.ProgressPlugin({
profile: this.options.progress === 'profile',
}).apply(this.compiler);
// for browser console output

Copy link
Member

@alexander-akait alexander-akait Nov 24, 2020

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

Copy link
Member

@alexander-akait alexander-akait Nov 24, 2020

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

Copy link
Contributor Author

@ylemkimon ylemkimon Nov 24, 2020

Choose a reason for hiding this comment

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

Should we add clientProgress or consoleProgress, or would it be too much? I'll move progress to client and remove profile.

Copy link
Member

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)

Copy link
Member

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

Copy link
Contributor Author

@ylemkimon ylemkimon Nov 24, 2020

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.

Copy link
Member

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?

Copy link
Contributor Author

@ylemkimon ylemkimon Nov 24, 2020

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.

@ylemkimon ylemkimon changed the title feat(options): merge profile option into progress feat: remove CLI progress output and move profile option into client Nov 24, 2020
@ylemkimon ylemkimon changed the title feat: remove CLI progress output and move profile option into client feat: remove CLI progress and move progress option into client Nov 24, 2020
@@ -106,7 +115,6 @@ module.exports = {
describe: 'Enable gzip compression',
group: RESPONSE_GROUP,
},
// findPort is currently not set up
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

@alexander-akait alexander-akait Nov 25, 2020

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

@alexander-akait
Copy link
Member

@ylemkimon @hiroppy Today I want to release [email protected]

  • Why not alpha? Because I think we should have done it earlier, but unfortunately I did not have enough time for this and I am very sorry
  • Why not rc or stable? I'm still afraid that we will need to make a pair breaking changes, but we really look stable

I want to hold beta this week and release rc or stable (after feedback) at the next week

What do you think?

@hiroppy
Copy link
Member

hiroppy commented Nov 25, 2020

Why not alpha? Because I think we should have done it earlier, but unfortunately I did not have enough time for this and I am very sorry

yes, me too. Not your fault

we have many breaking changes so beta is better I think. I want to see this version for more than 2 weeks because we don't check several platforms such as Electron so we will get many feedbacks..

@shaodahong
Copy link

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

@alexander-akait
Copy link
Member

⭐ I need some improvements on CLI side (webpack serve), ETA is tomorrow

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

/cc @hiroppy

@alexander-akait
Copy link
Member

@ylemkimon My idea right now - move client related options to the client option, for example overlay (https://github.com/webpack/webpack-dev-server/blob/v4/lib/options.json#L264), it is related only for client, why? So that in the future we can extract hmr/client logic into webpack-hot-module-replacement-middleware (maybe better name, feel free to provide good names) and avoid unnecessary breaking changes.

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) {
Copy link
Contributor Author

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.

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 fix it in the separate PR

@ylemkimon
Copy link
Contributor Author

@ylemkimon My idea right now - move client related options to the client option, for example overlay (https://github.com/webpack/webpack-dev-server/blob/v4/lib/options.json#L264), it is related only for client.

What do you think about:

  • injectClient
  • injectHot
  • useLocalIp

@alexander-akait
Copy link
Member

@ylemkimon I need think about it, let's focus on overlay

@ylemkimon
Copy link
Contributor Author

Should I open a new PR for overlay or update this PR?

@alexander-akait
Copy link
Member

@ylemkimon New PR

@alexander-akait
Copy link
Member

Let's merge this

@alexander-akait alexander-akait merged commit ecf2fe1 into webpack:v4 Nov 26, 2020
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.

4 participants