Support Local Tools

[justinmchase]

Description

Deno has some built-in tools:
https://github.com/denoland/deno/tree/main/tools

And deno supports installing user level scripts:
https://deno.land/[email protected]/tools/script_installer

But what if I have one repo that requires this particular version of a script but this other repo requires this other version of the same script? They both require the same command example but the two are not compatible... But they're installed at the user level so what am I going to do?

In nodejs if you install a dependency non-globally which exports a bin then you can use "npx" to invoke it relative to the current directly. Or add an npm script such as "compile": "tsc" which can be run with npm run compile and the local bin scripts are in the path and have the correct versions when run from the local directory.

Similarly .net core has an arguably better version of this same basic idea called "tools". One can run a command such as:

dotnet tool install dotnet-version-cli

Which then adds a file to your local repo at .config/dotnet-tools.json which looks like this:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "dotnet-version-cli": {
      "version": "2.0.0",
      "commands": [
        "dotnet-version"
      ]
    }
  }
}

And can then the tool be invoked via dotnet tool version.

Both techniques add the ability to have tightly controlled versions of tools for both developers and the CI servers, without any cross pollution between repos on the same machine. Any updates by tools are code reviewable and are automatically updated easily.

Proposal

So therefore I propose that it would be very handy if deno were to support a notion of local tools, so that the versions of said tools could be more strictly relied upon and limited to a given repo. A tool tool, so to speak.

Something like:

deno tool install -n example https://example.com/awesome/example/1.0.0/main.ts

Which would subsequently behave similar to the existing install command but it would add it to a subdirectory under the current directory such as .tools or .deno.

So now if I just run example it won't work automatically. Rather, instead I would invoke a deno command:

deno tool example

Which the implementation might be as simple as adding the .tools folder to your path and invoking the command.

Also it would be nice to have a supported file such as .config/deno-tools.json which would maybe look like:

{
  "version": 1,
  "tools": {
    "example": "https://example.com/awesome/example/1.0.0/main.ts"
  }
}

And could then be installed and run like this:

deno tool install
deno tool example

The one command would install all of the necessary tools for a given repo and would allow the repo to formally rely on those commands for automation.

Bonus Points

it would be really sweet if tools could be combined also, such as:

{
  "version": 1,
  "tools": {
    "echo": "https://example.com/awesome/example/1.0.0/echo.ts",
    "example" [
      "echo hello",
      "echo world"
    ],
  }
}

Where each line would invoke a tool one at a time such as deno tool $@, and would require each tool to return 0 to continue.

deno tool install
deno tool example
# hello
# world

[justinmchase]

Some updates after looking into this more.

Deno already supports locally scoped scripts, sort of, by allowing you to specify the directory the script is installed in via --root or DENO_INSTALL_ROOT env var. Of course that doesn't help you resolve the paths.

I created an installable script to help with this or act as a prototype called scripts:
https://deno.land/x/scripts

It allows you to create a scripts.json and in a single command script install install all of your tools into a local relative path. You can then invoke your tools using script run hello. That will add the local script dir to your path and then invoke the script. Its just shelling out to Deno to do the installs still.

[wperron]

I think you misunderstood the purpose of the tools/ directory on the deno repo (I admit, the README isn't the clearest) -- they are scripts that are used to contribute to the deno project, not built-in tools that are available to userspace.

[justinmchase]

Ok, I didn't look closely enough at them but I saw it had a lint and format which maybe don't map to deno lint and deno fmt but I guess that's what I was referring to, lint and fmt are some built-in functionality which may have previously be relegated to external tools.

[kitsonk]

No, when we build Deno, we can't guarantee to have the full deno runtime available to do our internal linting and formatting, especially if there is a bug with them, so they are included as standalone binaries, so we can avoid the chicken and the egg problem.

[justinmchase]

Got it makes sense