proposal: config module

[deer]

@iuioiua, this is the followup to denoland/fresh#2266 (comment).

I propose we introduce a type for the deno.json schema. I have a generator like this:

import configSchema from "https://raw.githubusercontent.com/denoland/deno/v1.41.0/cli/schemas/config-file.v1.json" with {
  type: "json",
};
import { compile, JSONSchema } from "npm:json-schema-to-typescript@13.1.2";

const result = await compile(configSchema as JSONSchema, "DenoConfig");
await Deno.writeTextFileSync("./config/configType.ts", result);

Maybe this type already exists, but I couldn't find it.

Additionally, there should be a suite of utilities for interacting with this configuration file. I propose two functions to start with:

1. readConfig -- This should read a path and parse the config file, handling a few things:
   a. Look for both deno.json and deno.jsonc files.
   b. Possibly look in parent directories, mimicking whatever the cli does in order to find the governing file.
2. importMap -- Return the relevant imports as Record<string, string>. This should handle both inline imports and also importMap.

[deer]

I should also mention that I have this implemented with 100% test coverage. (I'm aware that coverage isn't the end-all be-all, but it's better than having 0% coverage.) Let me know if I should open a PR for this.

[iuioiua]

What if we add a Config (or similar) interface to a std/deno module and keep it in sync with the runtime. We can then leave it up to the developers to read the file and use the interface as necessary. This would make use of deno.json available to all runtimes.

[boywithkeyboard]

@iuioiua I agree with you here, but wouldn't it make more sense to add such a type to the global Deno namespace?

[iuioiua]

That would mean only Deno programs have access to it. Having it in the Standard Library allows its use in other runtimes.

[boywithkeyboard]

@iuioiua this seems like outsourcing to me. Correct me if I'm wrong, but I don't think the type definition is relevant outside of Deno, at least not that I can think of a valid use case for it.

2 more reasons to keep it in the same codebase as the runtime itself:

• the runtime parses it & already provides auto-completion/a json schema for it
• that way it's kept in sync with the runtime and you don't suddenly end up with a type declaration that is different from what the runtime can understand/parse