On this page we reflect on the trade offs associated with the various options for managing the version of Deno used in denowiki.
Stability
Deno's APIs are not yet stable. Some examples are noted.
v0.30.0 does not have the encoding/base32 library.
v0.30.0 does not have the posix library (or its location is different).
v0.34.0 references Deno.errors which does not exist in v0.35.0.
v0.35.0 does not have Deno.ErrorKind
Two Problems
The lack of API stability complicates development and usage of denowiki as we need to be sure all of our dependencies and all of our users are using the same version of Deno.
This is further complicated by a proliferation of version references in the source code and inconsistencies in which version of Deno is installed using the default installation instructions.
We will discuss each in turn.
Proliferation of references to versions
Importing by URLs that include embedded versions results in a large number of files needing to be updated with each Deno version bump.
Static imports require a string literal so a string template cannot be used to reference an imported constant when importing a Deno dependency.
Switching to the import function everywhere may be a workaround, but does not feel idiomatic to the language.
Using unversioned URLs avoids the need to update URLs, but at the cost of requiring all developers to be diligent in staying up to date. Otherwise, we risk things working for some contributors and not others depending on when they last refreshed their cached dependencies.
It also requires that the project stay on the latest version of Deno as the moment a new version is published, it will be used by all new installs or refreshes of existing installs. We lose control of when we upgrade our Deno version.
An alternative here is to vendor our dependencies. This could be done by embedding a copy of the Deno dependencies directly in the project, by hosting a copy ourselves in a location controlled by the project, or by running a URL redirection service pointing to the version we want used.
This is far more work for us, but does have the advantage of allowing us to use unversioned URLs whose upgrade pace is controlled by us.
A lighter weight vendoring approach would be to create a top level file containing the imports of all Deno dependencies. All files in the project would then import the subset they need from this.
This centralizes where the imports are stored, is compatible with the idiomatic form of normal imports, and still allows us to reference a specific version of Deno dependencies without proliferating them over the codebase.
This approach is mentioned in a Deno FAQ on importing third party code. See the question that mentions deps.ts. site 
The downside is that it requires that all files in the project import this file which is a bit messy and all but eliminates the possibility of being able to write meta-sites and meta-pages without importing anything from the denowiki project.
Deno provides a URL import abstraction mechanism named import maps. Using this approach, imports would reference prefixes that are mapped to actual URLs or files. site
This approach has the advantage of being usable by remote meta-sites and meta-pages without requiring those resources to know where the needed dependencies are hosted.
The downside is yet another parameter required to run the project.
Default Deno Install Instructions
The default Deno install instructions result in different versions being installed on different platforms.
At the time of this writing Powershell results in v0.35.0 being installed while brew installs v0.34.0. brew
Options
The majority of users run macOS. When upgrading, it makes sense to only target versions installable by brew (at least while this remains true).
Alternatively, we could recommend everyone use a shell / powershell based installation mechanism as it appears to be able to install the latest version of Deno. web
It also reduces the number of distinct packages that need to be updated before a specific version of Deno can be installed across all supported operating systems.
Regardless of the version chosen, our README should name the version required and provide instructions on how to install that version on all supported operating systems (at least until the instructions for installing the latest version of Deno result in the same version being installed across operating systems or the Deno API stabilizes).
See Deno vs NPM for a comparison of their approaches to package management.