denoland
Built-in version manager
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,
denoupwill 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
denoVersionorengines.denoproperty (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:
- denoup: the version manager for the toolchain
- deno wrapper executable: the executable that will be mapped to the
denocommand, but will only check the version restriction and forward the command to the deno executable if the restrictions are satisfied. - 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
This might help:This file might fix it https://bit.ly/4evXrQ6
you may need to install the c compiler
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.
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.
