dprint 0.55: npm specifiers and node resolution

dprint is a pluggable and configurable code formatting platform that unifies all your formatters—run one command and format everything.

Version 0.55 is a substantial release, but this post will focus on why npm specifiers have landed in dprint. If you'd rather read the full outline of what's new, see the release notes.

Background

dprint currently supports defining formatting plugins via https: or relative specifiers in its configuration file:

{
  "plugins": [
    // note: these plugins run sandboxed in a Wasm runtime
    // and for additional security you can optionally specify
    // a checksum here
    "https://plugins.dprint.dev/json-0.22.0.wasm",
    "https://plugins.dprint.dev/typescript-0.96.1.wasm"
  ]
}

This has been nice, especially inside a company because you can host your plugins on a simple internal HTTP server and dprint will download, cache, and run the plugins.

For people outside a company, they can also use plugins from any HTTPS URL, but practically most people use the plugins.dprint.dev service, which serves plugins from GitHub repos based on GitHub releases.

A problem for people using plugins.dprint.dev is that I'm an individual. What happens if I can no longer maintain plugins.dprint.dev? I'm not an organization of people.

Previously, I always thought people could easily just update the URLs to point directly at GitHub because historically plugins.dprint.dev was just a redirect service to GitHub releases (ex. just update the URL to https://github.com/dprint/dprint-plugin-json/releases/download/0.22.0/plugin.wasm).

Unfortunately, due to AI, GitHub had to lower their rate limits for unauthenticated requests. This led me to have to change plugins.dprint.dev from a redirect service into one that caches the assets and serves the plugins directly.

Overall, this is not a great place to be long term. I could work on improving the organization behind plugins.dprint.dev, but it's a bit of wasted effort when there are already free registries maintained by large companies.

Moving to npm specifiers

For that reason, you can now reference formatting plugins via an npm: specifier in a dprint.json file.

Run:

dprint add npm:@dprint/json npm:@dprint/typescript

Which causes the dprint.json file to have:

{
  "plugins": [
    "npm:@dprint/json@0.22.0",
    "npm:@dprint/typescript@0.96.1"
  ]
}

This causes dprint to download the plugins from npm without a node_modules folder and format with them.

Commands like dprint init, dprint add, and dprint config update still recommend the plugins from plugins.dprint.dev. I'm waiting to get more feedback on this feature and ensure it works properly before making it the default out of the box.

Why npm?

For all the problems npm has for JS development, it's a dependable host for binary assets, which is perfect for dprint plugins. It handles versioning, caching, and integrity. It isn't going anywhere, and it lets plugin authors take advantage of extra security measures like trusted publishing.

Another reason is I had already been publishing the plugins to npm because they work when imported from JavaScript.

Bring your own npm package manager—node resolution

Additionally, you can now install dprint plugins as a dev dependency with your favourite npm package manager:

npm install --save-dev @dprint/json @dprint/typescript

This will cause your package.json to contain the following:

{
  "devDependencies": {
    "@dprint/json": "^0.22.0",
    "@dprint/typescript": "^0.96.1"
  }
}

Now add them to the dprint configuration file:

dprint add npm:@dprint/json npm:@dprint/typescript

Since it's a dev dependency in the package.json, dprint will add the plugins without a version number:

// dprint.json
{
  "plugins": [
    "npm:@dprint/json",
    "npm:@dprint/typescript"
  ]
}

Then use node resolution to resolve the plugins (commonly to node_modules/<package_name>/plugin.wasm).

Personally, I don't think relying on the node_modules directory is as nice because it requires remembering to run npm install when any of the plugin versions change. Overall, I wouldn't recommend this option, but it might be nice for teams with strict requirements.

Again, you can read the full outline of what's new in the release notes on GitHub.