vote: add option to control progress bar vanish timeout about webpack-plugin-serve HOT 10 CLOSED

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

from webpack-plugin-serve.

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.

from webpack-plugin-serve.

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?

from webpack-plugin-serve.

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.

from webpack-plugin-serve.

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.

from webpack-plugin-serve.

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 😄

from webpack-plugin-serve.

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?

from webpack-plugin-serve.

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?

from webpack-plugin-serve.

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

from webpack-plugin-serve.

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

from webpack-plugin-serve.