Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: add Deno.ConfigFile #24628

Open
iuioiua opened this issue Jul 18, 2024 · 8 comments
Open

proposal: add Deno.ConfigFile #24628

iuioiua opened this issue Jul 18, 2024 · 8 comments
Labels
suggestion suggestions for new features (yet to be agreed) types Issues related to TypeScript types

Comments

@iuioiua
Copy link
Contributor

iuioiua commented Jul 18, 2024

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).

@iuioiua iuioiua added suggestion suggestions for new features (yet to be agreed) types Issues related to TypeScript types labels Jul 18, 2024
@dsherret
Copy link
Member

dsherret commented Jul 18, 2024

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
Copy link
Contributor Author

iuioiua commented Jul 18, 2024

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
Copy link
Member

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

@iuioiua
Copy link
Contributor Author

iuioiua commented Jul 19, 2024

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

@lino-levan
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

iuioiua commented Jul 23, 2024

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

@lino-levan
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion suggestions for new features (yet to be agreed) types Issues related to TypeScript types
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants