denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
97k stars 5.36k forks source link

Built-in version manager #25724

Open halvardssm opened 1 month ago

halvardssm commented 1 month ago

Introduction

This Issue builds upon the previous issue https://github.com/denoland/deno/issues/5214 and relates to https://github.com/denoland/deno/issues/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

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:

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

didac-pf commented 3 weeks ago

Just commenting to raise visibility on the deno task --sync-version [TASK] proposed by @halvardssm. I think that's the way to go, letting deno handle (and download, if applies) the proper version for the project about to be executed.

Of course, this does not exclude allowing manual version handling via denonup or whatever name you guys come up with.

mayank99 commented 2 weeks ago

Related but tangential topic: indicating the version of Deno that a project uses in deno.json. Even if Deno doesn't automatically sync the version, it would be useful to still raise a CLI error when the wrong Deno version is used.

Node handles this via a package.json#engines field and a related engine-strict config.