Tooling: Add volta versions

[sirreal]

Changes proposed in this Pull Request

https://volta.sh/

This prepares the environment for use with Volta, a potential replacement for nvm (but more).

It sets a volta property in the root package.json. It also points all the other package.json in the repo to extend that root config. This is under the assumption that all tooling should use the version in the root.

It was a little annoying to add a volta property to every package.json, but that should be a one-time thing and doesn't seem like it should have any negative impact. That seems to be the way to do things in Volta at the moment. See volta-cli/volta#906 and the Workspaces docs.

Testing instructions

You'll need to set your system up for Volta. I have no idea if that will play well with nvm. I've removed nvm from my system completely.

From an arbitrary location like ~, install some volta tools (that don't correspond to the versions in Calypso). For example:

• volta install node@latest
• volta install typescript@beta

Check the versions with volta list:

$ volta list
⚡️ Currently active tools:

    Node: v15.6.0 (default)
    npm: v6.14.11 (default)
    Yarn: v1.22.10 (default)
    Tool binaries available:
        wp-env (default)
        neovim-node-host (default)
        tsc, tsserver (default)
        yarn-deduplicate (default)

$ node --version
v15.6.0
$ tsc --version
Version 4.2.0-dev

move to Calypso and check the versions:

$ volta list
⚡️ Currently active tools:

    Node: v12.20.1 (current @ /Users/jonsurrell/a8c/calypso/package.json)
    Yarn: v1.22.10 (current @ /Users/jonsurrell/a8c/calypso/package.json)
    Tool binaries available:
        wp-env (default)
        neovim-node-host (default)
        tsc, tsserver (current @ /Users/jonsurrell/a8c/calypso/package.json)
        yarn-deduplicate (default)

# Nice, volta picked up different versions! Let's check…

$ node --version
# installs on demand if necessary!!
v12.20.1

# It detects the package's version and prefers it!
$ tsc --version
Version 4.1.3

Repeat from another directory with a package.json such as packages/*/ or apps/editing-toolkit or client.

[matticbot]

Test live: https://calypso.live/?branch=add/volta-pin

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[matticbot]

Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

D55743-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2

[sirreal]

Looks like renovate should support: renovatebot/renovate#4262

[noahtallen]

I did a bit of testing with nvm + volta, and it looks like if NVM is configured in .the zshrc file, then it overrides volta. nvm use sets to 12.x, and that persists when changing to other directories. (e.g. the volta version is not used)

When nvm is not set in .zshrc, it works as expected:

It appears that nvm still works fine with volta config available. So in other words, this shouldn't break anything for existing users :)

I'm all for this, as I've been getting frustrated by NVM. For example, if I try to do a git commit or push via Visual Studio Code's GUI, the precommit hooks will utilize the "default" node version rather than the local nvm node version, which sucks when different projects use different node versions.

After trying out the precommit hooks with volta, it looks like that problem is finally solved! My editor is using the node version for the project without any intervention. (Tried with both wp-calypso and gutenberg using your branches.)

[scinos]

How does this interact with the version set in .yarnrc?

[sirreal]

Part of the yarn executable's behavior is to get the correct version via .yarnrc, isn't it? I did a test by pinning yarn@1.21 for volta. You can see that although volta will invoke it's yarn@1.21.1 binary, yarn reports its version is 1.22.10. I think everything will work smoothly and ultimately .yarnrc determines the version like I'd expect.

# volta list
⚡️ Currently active tools:

    Node: v12.20.1 (current @ …/calypso/package.json)
    Yarn: v1.21.1 (current @ …/calypso/package.json)
    Tool binaries available:
        wp-env (default)
        neovim-node-host (default)
        stryker (default)
        tsc, tsserver (current @ …/calypso/package.json)
        yarn-deduplicate (default)

See options for more detailed reports by running `volta list --help`.
# yarn --version
1.22.10

[scinos]

Seems weird and confusing to have a yarn version defined in two places. Do we really need to tell volta about yarn version?

What's the dev experience if we drop the version in .yarnrc and we want to update yarn?

[sirreal]

If we go all-in with volta, I believe we could safely drop either one.

What's the dev experience if we drop the version in .yarnrc and we want to update yarn?

I don't understand the question. Updating yarn via volta means running volta pin yarn@latest in the repo root.

[scinos]

Let's say we drop .yarnrc and we pin yarn using volta to a specific version (1.22.10).

How do update the version? I guess it is only a change in package.json, right?

What happens when a dev checks out a branch that points to a version they don't have locally? Does volta automatically downloads the new version?

[sirreal]

How do update the version? I guess it is only a change in package.json, right?

Yep.

What happens when a dev checks out a branch that points to a version they don't have locally? Does volta automatically downloads the new version?

Yes.

[scinos]

It is great that we are looking for alternatives to NVM if NVM is causing problems. Could you expand on the problems we are trying to solve with volta?

In any case, I think that we should only have one tool to do one thing. In other words, if we go ahead with this change, it should be a migration from nvm to volta with the aim of removing nvm from our system. Otherwise we are increasing the maintenance burden and the risk of `nvm

[lynnbgriffith]

It is great that we are looking for alternatives to NVM if NVM is causing problems. Could you expand on the problems we are trying to solve with volta?

I found @noahtallen’s comment on the related Gutenberg PR helpful in this regard. With volta, you no longer need to nvm i && nvm use. Instead, you should automatically use the correct node version for the project. That’s nice when on an interactive shell but perhaps more useful in the context of other tools that might otherwise end up using the incorrect version.

Dropping nvm in Calypso would be fine with me.

[creativecoder]

FYI, I'm proposing the same change in Jetpack: Automattic/jetpack#19705

[noahtallen]

I do like the ergonomics of Volta a lot, and have been using it exclusively recently, even without these changes. I wonder what our next steps should be? Do we need to commit to nvm or volta, or can we support both at the same time? (I don't see supporting volta as having a high cost, since it just involves bumping the version in the root package.json whenever we update node.)

Relatedly... I really, really wish they had not gone with this approach for monorepos. It seems to be the largest source of concern for project adoption since it increases the surface area by so much.

[scinos]

I wonder what our next steps should be? Do we need to commit to nvm or volta, or can we support both at the same time?

I still think we should draft a plan to do a full transition from NVM to Volta. IMO, at the very least we need (in no particular order):

• Change our Docker images to use Volta instead of NVM
• Write P2s explaining the difference, defining the transition plan and in general educating our devs about the new tool.
• Land this PR.

Nice to have:

• Clean up all those package.json. As @sirreal said, only a few of those will actually need volta (let's say only those that define 'scripts'?). Eventually get rid of the "fake" package.json files, this is not the first time they cause troubles.
• Detect when someone is using node from nvm, and warn them (example: have a pre-install hook that warns if the node binary is from ~/.nvm/versions/node/v*/bin/node)

[creativecoder]

I still think we should draft a plan to do a full transition from NVM to Volta. IMO, at the very least we need (in no particular order): ...

That all seems good to me.

Note that I still have nvm installed and volta seems to take precedence when running shell commands for which version of node and any npm installed binaries are used.

[sirreal]

I can draft or help with a p2 post. I'd recommend upgrading to Node 16 first (p7H4VZ-31V-p2) so everyone gets native Node binaries with Volta.

[github-actions]

This PR has been marked as stale due to lack of activity within the last 30 days.

[matticbot]

Link to Calypso live: https://calypso.live?image=registry.a8c.com/calypso/app:build-16074
Link to Jetpack Cloud live: https://calypso.live?image=registry.a8c.com/calypso/app:build-16074&env=jetpack

[sirreal]

This is very stale, I'll close it now. If there's interest and a desire to move forward with this I'd be happy to get this ready again.

[noahtallen]

Totally. I really wish they would just support reading from a higher-level .json file! I also looked into manual pinning -- like if I could achieve automatic version switching via a file I could add to .gitignore, but that also isn't supported :(

So I'm back to nvm for now, just because both Gutenberg and Calypso use it.

[scinos]

I really wish they would just support reading from a higher-level .json file

For the record, they kind of do, with extends. Docs.

[noahtallen]

Oh hey! Hope things are going great :D That's what this PR was exploring originally

[creativecoder]

I'm following this issue in the volta repo, but there hasn't been much movement: volta-cli/volta#282