fix: avoid using eval to get the corepack version

[merceyz]

What's the problem this PR addresses?

#42 used eval to get the current corepack version which doesn't work if the path to corepack isn't .../node_modules/corepack

How did you fix it?

Use a statically analysable require

[arcanis]

Only the reliance on the Node resolution is a problem, the eval should be kept. Otherwise Webpack will bundle the package.json inside the generated file, which is what I wanted to avoid.

[ljharb]

Typically that’s avoided with webpack config, rather than altering code to please a bundler.

[aduh95]

There are other solutions, such as https://github.com/andrewimm/babel-plugin-inline-package-json.

[arcanis]

Right, but this one works portably without requiring extra configuration that future readers would have to be aware of. I'm not sure I see a practical issue here (apart from the corepack/package.json string which should just be ../package.json).

[aduh95]

Future readers would have to be aware we are using eval to hack around Webpack, this PR suggests a cleaner solution I think. And it works without any extra configuration, or maybe I misunderstood what you meant by that.
If you do add some extra configuration though, it can address your concern of Webpack inlining the whole package.json file (either by embedding only the version string, or by leaving the require() call in the bundle file).

[ljharb]

Pretty sure you can also do (0, require) without using eval or configuring webpack.

[arcanis]

Let's include the package.json then.

Pretty sure you can also do (0, require) without using eval or configuring webpack.

That would generate a warning on Webpack (and an exception on other bundlers), due to them detecting the use of require in a non-static-analyzable way.