webpack-bundle-analyzer icon indicating copy to clipboard operation
webpack-bundle-analyzer copied to clipboard

[Feature request] option too choose web browser

Open jimblue opened this issue 5 years ago • 12 comments

Hi,

Actually webpack-bundle-analyzer doesn't offer an option to choose which browser open.

The option can only be set to default or null.

As many people use a different browser for development than for browsing it could be nice to have such choice.

Cheers

jimblue avatar Oct 16 '18 23:10 jimblue

Hey,

Any update about this?

Cheers!

jimblue avatar May 02 '19 01:05 jimblue

The underlying package we use is opener and it will open the default browser you've configured.

I'd like to avoid adding a new configuration option for the browser, so I'm hesitant on adding this feature.

valscion avatar May 02 '19 06:05 valscion

Hey!

Why not? It will not break anything, only add flexibility, which is always good 😄!

Consider that peoples often use two browsers, it would be a nice feature to add:

  • the default OS browser for everyday use to keep deep integration with the system
  • google chrome browser for development (the more often)

Cheers

jimblue avatar May 02 '19 07:05 jimblue

It could be also useful for developer using webpack-bundle-analyzer in their library...

jimblue avatar May 02 '19 07:05 jimblue

To make it even better, I'll suggest to replace opener with open. This package have more stars and is better maintain. Also the API is way better. it has much more options and it return a promise when the opened app exit. 😃

jimblue avatar May 02 '19 07:05 jimblue

which is always good

Additional flexibility is a double-edged sword. It makes the API surface larger, making the tool harder to use as documentation grows longer. Adding new options also introduces maintenance burden as we will need to make sure the new feature does not accidentally break.

We don't currently have the testing infrastructure for the openAnalyzer flag, and adding more features like that will make it much more likely for us to break it in the future.

So that is why I am not eagerly adding this feature.

valscion avatar May 02 '19 09:05 valscion

Additional flexibility is a double-edged sword

I would be agree if it was a huge add, but it's just easy as passing browser argument from webpack-bundle-analyzer to open.

How could that break anything or make future that more complicated?

I don't get it honestly...

jimblue avatar May 02 '19 11:05 jimblue

I would probably wait until https://github.com/sindresorhus/open/issues/116 is implemented.

sindresorhus avatar May 03 '19 11:05 sindresorhus

Thanks @sindresorhus, looks like that would indeed help.

valscion avatar May 06 '19 06:05 valscion

FWIW: Until/if this is supported, you can hack around it with a script that overrides xdg-open or open on Linux and Mac.

e.g. I put this script named xdg-open in a directory that comes before /usr/bin in $PATH.

#!/bin/sh

if test -n "$XDG_OPEN"; then
	$XDG_OPEN "$@"
else
	/usr/bin/xdg-open "$@"
fi

And it allows me to choose my browser in the package.json script e.g. XDG_OPEN=browser ...webpack-build-command....

DisposaBoy avatar Apr 15 '20 09:04 DisposaBoy

Hi there, Just a friendly ping as the dependency issue seems close now : https://github.com/sindresorhus/open/issues/116 Is this issue status is still blocked ?

jimblue avatar Sep 25 '21 23:09 jimblue

Might not be, maybe a dependency bump is needed with this feature. Feel free to create a PR :)

valscion avatar Sep 26 '21 04:09 valscion