Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[Feature request] option too choose web browser #216

Closed
jimblue opened this issue Oct 16, 2018 · 12 comments
Closed

[Feature request] option too choose web browser #216

jimblue opened this issue Oct 16, 2018 · 12 comments

Comments

@jimblue
Copy link

jimblue commented Oct 16, 2018

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
Copy link
Author

jimblue commented May 2, 2019

Hey,

Any update about this?

Cheers!

@valscion
Copy link
Member

valscion commented May 2, 2019

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.

@jimblue
Copy link
Author

jimblue commented May 2, 2019

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
Copy link
Author

jimblue commented May 2, 2019

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

@jimblue
Copy link
Author

jimblue commented May 2, 2019

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. 😃

@valscion
Copy link
Member

valscion commented May 2, 2019

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.

@jimblue
Copy link
Author

jimblue commented May 2, 2019

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...

@sindresorhus
Copy link

I would probably wait until sindresorhus/open#116 is implemented.

@valscion
Copy link
Member

valscion commented May 6, 2019

Thanks @sindresorhus, looks like that would indeed help.

@DisposaBoy
Copy link

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....

@jimblue
Copy link
Author

jimblue commented Sep 25, 2021

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

@valscion
Copy link
Member

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

@webpack-contrib webpack-contrib locked and limited conversation to collaborators Feb 23, 2023
@valscion valscion converted this issue into discussion #565 Feb 23, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

4 participants