Provide deno fmt and deno lint as runtime APIs

[kitsonk]

To compliment Deno.emit() we should consider providing runtime access to the formatting and linting APIs.

[dsherret]

FWIW, it's currently possible to use the formatter with the following code:

import { createStreaming } from "https://dprint.dev/formatter/v2.ts";

const [tsFormatter, jsonFormatter, mdFormatter] = await Promise.all([
  // see https://plugins.dprint.dev for latest plugins
  createPlugin("https://plugins.dprint.dev/typescript-0.45.0.wasm"),
  createPlugin("https://plugins.dprint.dev/json-0.11.0.wasm"),
  createPlugin("https://plugins.dprint.dev/markdown-0.7.1.wasm"),
]);

// outputs: "const t = 5;\n"
console.log(tsFormatter.formatText("file.ts", "const   t    = 5"));
// outputs: "{}\n"
console.log(jsonFormatter.formatText("file.json", "{       }"));
// outputs: "# test\n"
console.log(mdFormatter.formatText("file.md", "#   test"));

async function createPlugin(url: string) {
  const formatter = await createStreaming(fetch(url));
  formatter.setConfig({}, { deno: true });
  return formatter;
}

Advantage, similar to what was discussed about exposing the AST, is that the code works the same way regardless of what version of Deno is running it. The downside is that it's slow to initially download and then each time compile the Wasm (Side note: I'm guessing Wasm compiling could eventually be serialized and deserialized for faster re-runs... it should be able to eventually load it in under 100ms (5-30ms on my machine) like what dprint CLI does with plugins on subsequent runs).

[kitsonk]

For exposing the AST I would still be a bit 🤷 as you can't do that with the CLI. On the other hand, formatting and linting I would argue a bit more strongly for, because they are already exposed as subcommands on the CLI.

[bartlomieju]

We've been punting on this and related issues (#4531) for some time. The effort in exposing these APIs will be non-trivial with lots of questions around permission checks and DX related to that.

I'm not sure I'm in favor of adding these APIs, seems to me like spawning a subprocess to run the CLI commands is easier solution. I'll be happy to reconsider if someone provided use cases where using a subprocess approach is not desirable.

[dsherret]

I think similar to the future of Deno.emit these should be distributed as modules. That way they would be behind a semantically versioned API and decoupled from the runtime.

[remyrylan]

My immediate thought about distributing any of these features (especially Deno.emit) as modules behind a versioned API is that it opens up the possibility to produce formatted/output code that couldn't run in your current version of Deno.

That would be pretty confusing to a developer new to Deno... Imagine using something like deno.land/std@1.0.0/emit/mod.ts, running some code through it, producing NO errors, and then getting an error when trying to run the produced code because the code from the emit module allowed for some new syntax in the latest version of V8 or something that your current version of Deno is not expecting.

So at the very least, I think it would be incredibly necessary that if these modules do end up being distributed via deno.land that there must be a runtime version check within the modules, so that they can throw an error to let you know that they are incompatible with your version of Deno...

[lucacasonato]

We are not going to do this for the time being. One should use fmt and lint either through the CLI, or as a Wasm binary.

[jsejcksn]

One should use fmt and lint either through the CLI, or as a Wasm binary.

@lucacasonato Will you share a link to documentation that describes how to use Deno's formatter/linter as a wasm binary?