search

denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
97.23k stars 5.37k forks source link

proposal: add `Deno.ConfigFile` #24628

Open iuioiua opened 3 months ago

iuioiua commented 3 months ago

Sometimes projects have to read a deno.json file (e.g. in Fresh here). In such cases, having a type that makes working with the file easier, from the Deno.* namespace, could be quite helpful, and prevent users from having to come up with their own types (another example in Fresh here).

dsherret commented 3 months ago

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.

iuioiua commented 3 months ago

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.

dsherret commented 3 months ago

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

iuioiua commented 3 months ago

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

lino-levan commented 3 months ago

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.

BlackAsLight commented 3 months ago

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.

iuioiua commented 3 months ago

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

lino-levan commented 3 months ago

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.