volta respects engines property of package.json
Now volta creates own property volta and uses only it. It would be extremely convenient if volta have a look for volta prop first and if it's not found it looks for engines prop.
A few points:
- In most cases it's enough to specify only
majorversion inenginesprop of a tool instead ofmajor.minor.fix, likenode: ^16. But if a user needs to define a specific version he can do in usingvoltaprop. In the first case we don't need to duplicate the info about tool version. - In some cases a user can use
voltato work with a project, but other team mates don't. In this case commitingvoltaprop topackage.jsonis redundant and might be declined on a code review
This sounds as an good idea on first sense, but will lead to a breaking changes and unexpected behaviour for users who already using global node for some reason. Second issue with semver of such records, e.b. node: ^16 may not work with volta, as it expects exact version
While there were a couple of discussions about the usage of the engines field (#355, for example), in the latest Node versions there's an experimental corepack tool Volta can leverage for setting and referring to the current package manager and its version.
This sounds as an good idea on first sense, but will lead to a breaking changes and unexpected behaviour for users who already using global node for some reason. Second issue with semver of such records, e.b.
node: ^16may not work with volta, as it expects exact version
This have a very easy solution, if volta find the volta json configuration node, volta will give priority to that configuration.
As I said, It's a shame that you're not considering the proposal, it would be a great addition to Volta. I love Volta, and whenever I manage a project, I always add Volta configuration to my package.json. However, when I collaborate on a project, they usually don't want anything unofficial added to the package.json configuration, so most of the time, I can't use Volta.