I don't think this should be built-in because if breaking changes happen to the config (ex. like lint.files being removed) then the type will change based on what version of Deno the code is run with rather than the version of the deno config that the code supports.

Isn't that true for any type in the Deno.* namespace? Also, to be clear, I'm not strongly in favor of adding this either.

I don't think so because those are runtime APIs. Deno.ConfigFile would be a representation of something outside the JS runtime.

I think it still might provide more value than not having it. @marvinhagemeister, any thoughts?

I will reiterate my support here, though I understand and sympathize with David's hesitation. As a framework author, it really sucks just having to "guess" where the deno.json is going to be, and getting configuration options is only going to be harder as Deno workspaces roll out. I really don't want to end up in a node situation where every framework reinvents node's package.json resolving algorithm.

Maybe a new env variable that says the path to the config file that was used? Then when a module needs it, they can read the files content themselves, instead of requiring the user of the module to provide the path/info.

This is about having an interface that represents the deno.json file, not the actual content.

This is about having an interface that represents the deno.json file, not the actual content.

Ah sorry, right. I guess it was confusing because you closed #19322 "in favor" of this one when they are not doing the same thing. I misread the initial issue description.