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 #1918

Merged
merged 1 commit into from Aug 9, 2019

Conversation

feross
Copy link
Member

@feross feross commented Aug 8, 2019

Fixes: #1917

? function (id, opts, cb) {
if (!opts.basedir) opts.basedir = path.dirname(opts.filename)
resolve(id, opts, cb)
}
: bresolve
: typeof browserField === 'string'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we sure nobody is putting a string value now, and relying on it being a noop?

What if it's an empty string?

Copy link
Member Author

@feross feross Aug 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now any value other than false (including an empty string) just does normal "browser" field resolution.

We've never supported any value other than false for this argument and since this is an additive change, I'd argue it could be released in a minor version. But I'm also fine with releasing it in a major version to be extra safe, though I think it's a bit overkill.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, that was two questions :-) you answered the first, but not the second - after this PR, should an empty string be allowed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The simplest rule would be: if the type is string, then we look for that key in package.json and apply the "browser" field spec.

So, then an empty string would look for an empty string key in package.json.

But it's also likely to be a bug, so also I'm okay with throwing an exception in this case.

@feross
Copy link
Member Author

feross commented Aug 9, 2019

@substack took a look at this and said it looks good on IRC. I'm going to merge it now.

@feross feross merged commit 4c04949 into master Aug 9, 2019
@feross feross deleted the custom-browser-field branch August 9, 2019 05:25
@feross
Copy link
Member Author

feross commented Aug 9, 2019

16.5.0

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

Successfully merging this pull request may close these issues.

Support custom names for "browser" field resolution
2 participants