Introduction

This Issue builds upon the previous issue #5214 and relates to #24157

As we are closing in on a 2.0 release, I would like the team to reconsider a built in version manager similar to how rust has rustup. Having a version manager provided by deno will provide more stability for older projects, as well as for newer projects.

If this gets support from the Deno team, I would be happy to contribute with the code changes.

For the following, denoup will be used as a placeholder for the version management tool, it is not final.

Features

• Deno provides a built in package manager similar to rustup
• On a system, multiple deno versions can be installed
• By default, the latest local version will be used unless other is specified
• In a project, the deno version can be specified using a new denoVersion or engines.deno property (not both, we just have to decide on the better path)
• The version specified in a project is optional, and can be a semver or a semver range

Challenges:

Possible challenges will amongst other be backwards compatibility for deno versions that does not consider a deno version property. To get around this, the deno executable could be split up into three separate parts:

1. denoup: the version manager for the toolchain
2. deno wrapper executable: the executable that will be mapped to the deno command, but will only check the version restriction and forward the command to the deno executable if the restrictions are satisfied.
3. deno executable: this will be the main executable as is available now, but probably without the upgrade command as it will be handled by denoup. This executable can also be downloaded as a standalone e.g. for docker images.

Out of scope:

• Individual modules that are imported will not be handled by separate deno versions. It is up to the respective modules to provide support for deno versions.

User stories

A developer runs the installer script for deno. The script first installs a separate tool denoup, which will be executed to install the latest version of deno and set it as active. The developer would create a new deno project using deno init. The newly created deno.json will not contain the deno version property, so by default, the active deno version will be used.

A developer has deno version 1.2.3 installed on their system, and wants to clone a deno project from GitHub. The project has a deno.json file with the deno version ~1.0.20. The developer runs deno task run which compares the versions. The semver does not match the installed version so deno gives back an error saying that the engine version does not satisfies the requirements of the package. The output states Deno version is not satisfied, please run again with "--sync-version" or use the latest satisfied version by running "denoup use ~1.0.20" (optionally add "--latest" if you want to check for the latest allowed version).

A developer has deno version 1.2.3 installed on their system, and wants to clone a deno project from GitHub. The project has a deno.json file with the deno version >=1.1.1 <1.2.4. The developer runs deno task run which compares the versions. The active deno version is withing the range, so the script will run.

Existing work

• Node Version Manager (nvm)
• Deno Version Manager (dvm)
• Rustup