Skip to content
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

Support custom names for "browser" field resolution #1917

Closed
feross opened this issue Aug 8, 2019 · 2 comments · Fixed by #1918
Closed

Support custom names for "browser" field resolution #1917

feross opened this issue Aug 8, 2019 · 2 comments · Fixed by #1918

Comments

@feross
Copy link
Member

feross commented Aug 8, 2019

I'm packaging WebTorrent so it can be used in a Chrome App environment. This is for the built-in torrent support in Brave Browser.

The "browser" field is automatically used during bundling, but for Chrome Apps I'd like to do different substitutions than for normal browser. Specifically, I'd like to use e.g. chrome-net instead of net since Chrome Apps have access to raw sockets, but normal browsers do not. Therefore, I cannot add this substitution to the 'browser' field without breaking the normal browser build.

What I really need is a way to specify what field name in package.json should be used for the browser field resolution, with "browser" being the default.

Fortunately, browser-resolve already support such an option! The browser option allows the user to select which property name to use from package.json. It defaults to "browser".

I'd like to update the existing config option browserField to accept a string value, e.g. { browserField: 'chromeapp' } for this exact purpose. Currently, this config option is only used to disable the browser field entirely, e.g.{ browserField: false }, so we can add a new string option relatively easily. I think this is cleanest.

What do folks think?

@feross
Copy link
Member Author

feross commented Aug 8, 2019

Here's a PR: #1918 Feedback welcome.

@feross
Copy link
Member Author

feross commented Aug 9, 2019

FWIW, I just noticed that webpack accepts an aliasFields option that does exactly what I'm proposing for browserField here. Not that that's a reason in and of itself to support it. Just an additional data point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

1 participant