Volta: Reason to not use `package.json`'s `engines` key?

[ProLoser]

The package.json has a standard engines key. Is there a reason for not supporting this in notion vs creating a new toolchain key?

[charlespierce]

Hi @ProLoser, early on we discussed using engines. We ultimately decided there were a few issues with doing so, all related to Notion’s goal of repeatable builds / dev environments:

1. engines is typically used to represent the versions of node that your package will _work_ with, while toolchain is intended to represent the version that you _develop_ with.

2. engines in the docs only canonically supports node and npm keys, while we also want to support / track yarn.

3. The biggest issue, however, is that engines allows you to specify a Semver range specification for each tool. Due to the goal of repeatable builds, the version specified in Notion’s toolchain key are specific, resolved versions, and ranges aren’t allowed.

We’re also investigating (#282) supporting a separate .notionrc file to specify these values (among other configurations) as an option in place of the package.json key.

[ProLoser]

Ah interesting. I also just realized we worked in the same office together lol. You realize this is Dean, right?

[charlespierce]

I did :) Figured I’d answer the question first. How are things at PS? And out of curiosity, how did you hear about Notion?

[ProLoser]

I don't remember how, but it popped up somewhere during my research. I use fish shell so I've always run into huge problems with n and nvm and all the others. PS is good, I'm assuming you've read the news so yeah that's fun.

[charlespierce]

I actually hadn’t until now, but yeah, exciting!