vote: add option to control progress bar vanish timeout

[aaronjensen]

First of all, this package is fantastic. Great work, and thank you. The progress bar totally helps with a huge problem with webpack HMR... you just don't trust it and/or know when it has reloaded. It's great. That said...

Expected Behavior / Situation

I'd like to be able to see my full page immediately after an HMR and use the larger progress bar. The small one is nice, but not quite visible enough.

Actual Behavior / Situation

It takes 5 seconds for the progress bar to disappear, which means if what I'm looking for is obscured by the progress bar I have to wait a whole 5 seconds before I can see it after an HMR.

Modification Proposal

Make it configurable or remove the delay. Personally, I'd probably set it to 0, especially since the HMR seems to happen around 98% for me.

[shellscape]

Thanks for the kind words!

We chose the 5 second delay based on a lot of user feedback, and the average time switching between editor and browser being between 4 and 10 seconds. Granular control over client-side features isn't generally something we're open to adding (it conflates the options object, increases complexity for both the user and development/testing).

But we'll leave this open as a feature vote - if it gains 87 👍 votes we'll add the feature.

Vote thresholds are determined by using a whole number that is roughly 10% of the NPM downloads for the given month. If a feature isn't deemed acceptable or widely useful initially, it should meet the criteria of being useful to at please 10% of the user base. Thresholds are never raised, but they can be lowered.

[aaronjensen]

Got it, thanks for responding. For additional context, my monitor is wide enough that I have both my editor and browser visible at the same time. The time to switch is the time it takes me to move my eyes. Also, if things like https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview gain popularity, the switching time may go down.

I understand your concerns. One question--is it possible to provide my own progress option? You currently allow true and "minimal", could I register my own on the client and use that?

[shellscape]

You can absolutely do that. You'd want to clone one of the progress directories to your project (or a package) and make your modifications. From there you'd simply have to add the script as an entry in your development bundle. Should work out of the box.

[aaronjensen]

By the way, the voting thing is an interesting idea. Do you have any examples of votes reaching 10% of NPM downloads? I like the idea, but I wonder about assuming a 1:1 NPM downloads to real person ratio (for me alone I would be at least 3 npm downloads--home, work, CI), and that 100% of people that want a feature would be willing and able to find the issue and vote for it. I'm definitely not trying to say it's a bad idea, I just wonder about the specifics.

Also, thanks for the tip on the progress modification, I'll try it out. That'd probably solve it for me.

[shellscape]

I don't have any real metrics on it yet, but it's something we wanted to try for this because past experience with both webpack-dev-server and webpack-serve all pointed towards tons of requests for features that only ended up being used by a few folks. That was especially important when there are reasonable workarounds or alternative methods available. We also thought it was a good way to go because it's not shooting down a request, it's giving the user base the chance to speak as to whether or not it's wanted/needed on a wider basis than a single user.

This issue for unix sockets, for example #6 only needs 10 votes, but it's only had 2. That's a feature that both webpack-dev-server and webpack-serve bent over backwards to implement, but it doesn't appear that many people are truly interested in using it.

My guess is that we'd see a lot more participation if more people knew about the package. Hopefully you can help spread the word 😄

[aaronjensen]

You'd want to clone one of the progress directories to your project (or a package) and make your modifications.

Unless I'm missing something, it looks like I'd probably need to use a webpack alias to get my progress overlay in, or I'd need to actually clone the entire client directory, which is something I'd rather not do for maintenance's sake, or I'd need to make my own socket connection.

Maybe I'm missing something, though?

webpack-plugin-serve/lib/client/client.js

Lines 74 to 81 in 9f30145

	if (options.firstInstance) {
	if (progress === 'minimal') {
	const { init } = require('./overlays/progress-minimal');
	init(options, socket);
	} else if (progress) {
	const { init } = require('./overlays/progress');
	init(options, socket);
	}

[aaronjensen]

Got it working:

config.plugins.push(
    new webpack.NormalModuleReplacementPlugin(
      /webpack-plugin-serve\/lib\/client\/overlays\/progress\.js/,
      rootDir + '/src/webpack-plugin-serve-progress-fast.js')
    )
)

Related: would you accept a patch to make the progress bar invisible from first load instead of doing the current appear and immediately shrink/disappear thing it's doing now?

[thasmo]

What about relying on https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API to enhance the visibility/timing of the bar?

[shellscape]

@thasmo great suggestion. It looks like it's supported by the browsers we support as well: https://caniuse.com/#search=visibilityState.

[shellscape]

Would anyone in the conversation be interested in a opening Pull Request using the Page Visibility API?