Add browser field to package.json to fix webpack

[josephfrazier]

This should close #305, see #305 (comment):

Actually, after reading https://webpack.js.org/configuration/resolve/#resolvemainfields more closely, it sounds like adding a browser field to package.json, that points to lib/index.js (same as main) should fix things.

resolve.mainFields
[string]

When importing from an npm package, e.g. import * as D3 from 'd3', this option will determine which fields in its package.json are checked. The default values will vary based upon the target specified in your webpack configuration.

When the target property is set to webworker, web, or left unspecified:

webpack.config.js

module.exports = {
//...
resolve: {
mainFields: ['browser', 'module', 'main']
}
};
For any other target (including node):

webpack.config.js

module.exports = {
//...
resolve: {
mainFields: ['module', 'main']
}
};
For example, consider an arbitrary library called upstream with a package.json that contains the following fields:

{
"browser": "build/upstream.js",
"module": "index"
}
When we import * as Upstream from 'upstream' this will actually resolve to the file in the browser property. The browser property takes precedence because it's the first item in mainFields. Meanwhile, a Node.js application bundled by webpack will first try to resolve using the file in the module field.

I'll open a PR for that.

[slevithan]

Nice research. Based on the docs you linked to, this looks like it will indeed resolve the issue for anyone with webpack's target property set to webworker, web, or left unspecified.

@josephfrazier, do you think this should be released as a 4.4.1 or 4.5.0?

[josephfrazier]

Thanks! This feels like a 4.4.1 bugfix to me

[josephfrazier]

@slevithan are you going to take care of doing the release, or should I?

[slevithan]

@josephfrazier If you're okay with doing it, I'd really appreciate it! I'm trying to minimize involvement going forward :( But let me know if you run into any problems and I'll be happy to help!

[josephfrazier]

I should be able to dig up and do all the steps, especially now that you've made it easier with 760ab95

I'll give it a shot and reach out if there's any issues!

[josephfrazier]

@slevithan can I get collaborator access to this repo (https://github.com/slevithan/xregexp/settings/access)?

Specifically, I'd like to add a branch protection rule that requires the new github action check to pass on PRs: https://github.com/josephfrazier/xregexp/settings/branches

[slevithan]

@josephfrazier You already had collaborator access, so I'm not sure what's up. I just removed then re-invited you.

[josephfrazier]

Ohh, whoops. I think I meant to ask for maintain or admin access, so I can manage the repo settings at https://github.com/slevithan/xregexp/settings. Here's what it currently looks like for me:

[slevithan]

@josephfrazier I don't see any option to change collaborators' roles/permissions. I'm guessing that's because this is a personal repo, rather than owned by an organization.

I've gone ahead and created a branch protection rule. I set the branch name pattern as master and checked only the option "Require status checks to pass before merging" (with "build" as the selected status check). Let me know if you want me to make any further changes!

(If you continue to need admin access in the future, I'm open to discussing transferring the repo to an organization.)

[josephfrazier]

Thanks, that looks like it did the trick! For an example, see #312

I don't know if we need to bother with an organization yet, I'll see if I hit future barriers