Matches babel env preset instead of engine

[haysmike]

Hello! I've found a bug. The regex here also matches Babel preset options. I happen to be using the "node": "current" Babel env setting for a few projects, which causes the plugin to report package-json-engine: no version satisfying `current' installed. Let me know if you're open to PRs, thanks!

[jasonkarns]

Yes, thank you! Though I am not excited to iterate on tests of the regex ;)

[haysmike]

Are you open to pulling in jq as a dependency? The method in question could just do jq .engines.node $package_json_path

[jasonkarns]

Probably not, because there really isn't a way for this project to provide deps. Which means it would be considered an external dep that a user must install/configure on their own, instead of being self-contained (or installed automatically).

Consider the difference with the sh-semver script that is bundled within this project such that git-cloning the plugin within nodenv plugins just works.

We might consider it, but only as a last resort.

[jasonkarns]

On the flip side, I don't think that leveraging node itself would be terrible. We could almost assume a node existing in PATH somewhere. So perhaps porting the logic as a node script would solve the complexity, without adding a dep that isn't reasonably expected to be available. (Provided the node script only uses core apis and doesn't use any npm deps.)

[hurrymaplelad]

Thanks for the heads up! How 'bout JSON.sh, committed as node_module as we do with sh-semver?

PRs welcome!

[jasonkarns]

Oh nice! And JSON.sh looks fairly small, too. I'm 👍 on using it and vendoring as sh-semver.

(Though separately, I bet JSON.sh could use a PR that adds files to its package.json. They're including an awful lot of irrelevant files in their npm tarball.)

[haysmike]

Thanks for the guidance, I'll look into JSON.sh when I get a chance!