xxx.md

Package name: xxx (temporary name)

Update

xxx update: Updates the dependencies in the code. You can pass a list of patterns. For example:

• xxx update deps.ts Updates a file
• xxx update deps/*.ts Updates all files matching this pattern
• xxx update deps.ts deps/*.ts Updates all files matching several patterns

If the file has the extension .json or .jsonc, an import map is assumed. For example:

xxx update deno.json

Update configuration

I think configuration in the url imports is not a good idea. A centralized configuration gives more control. The configuration could be passed as CLI arguments, for example:

xxx update deps.ts --allow-unstable --allow-breaking

Or using a configuration file:

{
  "update": {
    "*": {
      "allow-unstable": true,
      "allow-breaking": true,
    }
  }
}

Using configuration files, it would be possible to configure specific packages. Example:

{
  "update": {
    "npm:name": {
      "allow-unstable": true,
      "allow-breaking": true,
    }
  }
}

Note: The configuration syntax is not defined, this is just an example. The idea is to allow to configure not only global options, but also options for a particular package or group of packages (example: @unocss/*). In fact, maybe TOML or YAML is a better format than JSON due it's intended to be written by humans.

Duplicates

Allows to search multiple versions of the same package:

xxx duplicates

It search all versions of the same package and merges it. It uses scopes field of the import maps to fix the duplicates. For example, with nudd:

nudd --duplicates file.ts --dry-run

The response is:

denoland:std
   0.210.0
     denoland:vento@v0.10.1
   0.212.0
     denoland:lume@v2.0.3

To fix duplicates, update the import map with the code below:

{
  "scopes": {
    "https://deno.land/x/vento@v0.10.1/": {
      "https://deno.land/std@0.210.0/": "https://deno.land/std@0.212.0/"
    }
  }
}

Find duplicates is quite harder that update because there are dependencies of dependencies. In nudd I use deno info to get the module tree and then process all the info.

I found a problem in Deno that doesn't support import maps for NPM packages. See issue here: denoland/deno#23459

So I didn't find a way to fix duplicates in NPM packages (I'm not sure if JSR has the same problem).

Add

It's a way to install a package in a Deno project. In the same way that duplicates modifies the scopes field of import maps, add modifies the imports field.

The idea is xxx add package-name will search this package in all registries and add an entry in the import map with this package name. If the same package is available in different registries, the user can decide which one want to use it. For example:

xxx add vento

Vento is available in:

1. https://deno.land/x/vento@v0.12.5/
2. npm:vento@v0.12.5

Maybe the tool should priorize Deno-specific registries. For example, use deno.land/x version automatically instead of npm.

Import maps

In the future, if the installed package requires to add some entries in the import map, the tool should be able to add them automatically. There are discussions about how to handle multiple import maps here: https://github.com/WICG/import-maps/milestone/5

This feature is not stable yet so I wouldn't include it.

Usage

The tool must be able to use it as:

• A js module: import { update } from "xxx";
• As a CLI tool: xxx update
• As a GitHub Actions uses: xxx/update