-
-
Notifications
You must be signed in to change notification settings - Fork 508
-
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
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 12 comments
-
Hey,
Any update about this?
Cheers!
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
It could be also useful for developer using webpack-bundle-analyzer in their library...
Beta Was this translation helpful? Give feedback.
All reactions
-
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. 😃
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
😕 1
-
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...
Beta Was this translation helpful? Give feedback.
All reactions
-
I would probably wait until sindresorhus/open#116 is implemented.
Beta Was this translation helpful? Give feedback.
All reactions
-
Thanks @sindresorhus, looks like that would indeed help.
Beta Was this translation helpful? Give feedback.
All reactions
-
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....
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi there,
Just a friendly ping as the dependency issue seems close now : sindresorhus/open#116
Is this issue status is still blocked ?
Beta Was this translation helpful? Give feedback.
All reactions
-
Might not be, maybe a dependency bump is needed with this feature. Feel free to create a PR :)
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1 -
🎉 1