Ways to get the Deno configuration

[ayoreis]

I would like and have use cases for a function in the Deno namespace that gets the current configuration file.

I thought of 3 forms this could come in (suggest any other ideas you have here):

• Deno.config would return an object representation of the current configuration file.
• Deno.configFile would return the file path to the current configuration file.
• Deno.beforeArgs, Deno.fullArgs and Deno.command would all return info of how the code was run (see comment below with the explanation).

The last could be used in more situations than to find the configuration file, so I think we should add both.

[deckchairlabs]

Yeah this would be so handy!

[peetklecha]

I came here to make the same request -- for library authors who want users to put config into deno.json, Deno.config would be very convenient!

[timreichen]

I would suggest to have it all methods/properties concerning config stuff in the same interface:

namespace Deno {
  export interface ConfigObject {
    tasks: Record<string, string>;
    importMap: ImportMap
    compilerOptions: CompilerOptions;
    …
  }
  export interface config {
    /**
     * returns the filePath of the deno.json or deno.jsonc file that was parsed by the runtime
     */
    filePath: string | null;
    /**
     * returns the resolved json or jsonc data that was parsed by the runtime
     */
    toObject(): ConfigObject | null;
  }
}

for the filepath it would be Deno.config.filePath, and Deno.config.toObject() for the data. Note: toObject is borrowed from Deno.env

@ayoreis what do you mean by Deno.beforeArgs Deno.fullArgs and Deno.command? What do they do?

[ayoreis]

@timreichen they are not really related to the config but to how the code was run, though I suggested them out because they would allow you to find the config file:

• Deno.beforeArgs like Deno.args but the one before the file path as --allow-net and --reload.
• Deno.fullArgs would be Deno.beforeArgs + Deno.args
• And Deno.command would be the entire command used to start Deno; deno run --allow-net --reload mod.ts 🦄 🌈.

These are not well thought out. I agree that all the config-related stuff should be under one object, I think these too:

namespace Deno {
    export interface command /* What do you think of these names? */ {
        type: 'run', 'bundle', 'test', ...
        options: ['--allow-net', '--reload'],
        mainModule: 'mod.ts', // Move this here (and rename it)? It would be a breaking change.
        args: ['🦄', '🌈'],
    }
}

[timreichen]

Ah, ok. I think it is better to open a separate issue for them since this issue is mainly about the config file.

[niedzielski]

I'm interested in this too! I have two use cases:

1. Active config: Get the currently set Deno config.
2. Closet config: Resolve the config closest to a source file or directory.

I think everyone needs 1. I want it just to access config settings generally.

I need 2 to locate a Deno config using whatever algorithm Deno would. For example, I want to build project_a so I need to locate the project_a config:

$ ls
/work
  tools/
    deno.json <-- I am the config for executing build.ts itself.
    build.ts
  project_a/
    a.ts
    deno.json <-- I am the config needed to build a.ts that a build tool needs to know about.
  project_b/
    deno.json

$ cd project_a
$ ../tools/build.ts a.ts 

Right now I have projects manually specify the config like ../tools/build.ts a.ts $PWD/deno.json but I'd like to locate the config closest to a.ts so it can be inferred from the a.ts source input instead.