Remove hasown package from dependencies

[takaram]

This PR removes hasown from package.json and replaces it with Object.hasOwn.

The package is useful when you need to support old JS runtimes which don't have Object.hasOwn, but it is not the case with licensee.js anymore as all supported Node.js versions have Object.hasOwn.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn#browser_compatibility

[ljharb]

It's also useful to prevent breaking when someone does delete Object.hasOwn, which has nothing to do with node.js versions.

[kemitchell]

I almost certainly added this dep to clear an ESLint warning about the potential global prototype mutation.

[takaram]

Thank you for your feedback!

It's also useful to prevent breaking when someone does delete Object.hasOwn, which has nothing to do with node.js versions.

This is technically correct, but I don't think we need to account for such cases here.
If we need to account for this kind of global mutation, we would also have to avoid built-in methods such as Object.keys and Array.from, which are already used in this project.

I almost certainly added this dep to clear an ESLint warning about the potential global prototype mutation.

Object.hasOwn is not affected by mutations to Object.prototype, so I don't believe this should trigger that warning.

[kemitchell]

I gather Object.hasOwn dates back to Node 16. We've now seen tests pass on Node 20.

I'm not reflexively afraid of small-package dependencies. But hasown was fundamentally about shimming a language feature, and as @takaram has pointed out, the language and its runtimes have caught up.

@takaram would you like to push a commit adding yourself to contributors in package.json?

I'd also appreciate a quick comment on the PR that you're licensing Apache 2.0, like the rest of us.

[ljharb]

@kemitchell this is totally fine ofc, but to be clear it's not fundamentally about shimming a language feature - that's https://npmjs.com/object.hasown - it's fundamentally about providing the functionality in a way that's robust to builtins being mutated.

[kemitchell]

@ljharb, you're clearly right about your own packages. Thanks again for contributing them. As you can tell, I've been a user!

I'm seeing the current rec, e.g. ESLint's, is to sub Object.hasOwn for object.hasOwnProperty. I'm fine getting in line with that. And as much as little packages do not bother me, especially from people I trust, I won't be sad to see hasown go, given @takaram's point about Node 20+.

I'm generally fine telling anybody who mucks with built-ins—globals or prototypes—that it's not part of my API to aid and abet them in monkey-patching the platform. I could see this as a patch release.

[takaram]

I'd also appreciate a quick comment on the PR that you're licensing Apache 2.0, like the rest of us.

I agree to license my contributions under Apache License 2.0.

[kemitchell]

I agree to license my contributions under Apache License 2.0.

Thanks!