Deno: Idea: config file (e.g. .denorc.json)

Created on 30 Dec 2018 · 3Comments · Source: denoland/deno

I think it will be cool to add something like .denorc.json or similar for storing config.
Example use case: web server, add allow-net property to the .denorc.json instead of passing it every time when running app.

Source

sh7dm

Most helpful comment

Hello I was wondering if this is never going to happen in Deno? I mean a config file is something that would be very nice to have in larger projects, rather than using a bash script or alias to run the project.

The concern of unrestricted access was raised, but couldn't that be resolved by simply on first run warning the user what permissions are required and asking them if they still want to run it. Maybe 3 options: Yes run it, Yes run it and don't ask me again, No don't run it

The config file for me is not as much of running unknown code, but rather of running larger projects. It would be nice to be able to run a project from a year ago without having to wonder what permissions it requires, or needing to rely on OS specific solutions to bypass it (bash scripts / aliases)...

More importantly if you don't add this to the Deno someone else is going to create a runner for Deno that supports config files. Isn't it better to have control of the config file and making sure that it is handled as securely as possible, rather than having a wild-west of runners?

In conclusion here is a simple demo config structure:
https://gist.github.com/mauritzn/04d8a6e910d6612356d4daf231c7a6d1

The "main" config option would be so that you could just run "deno run" and not have to specify a file. Also would not recommend having the config file as a hidden file like suggested (.denorc.json), but rather something visible like deno-config.json.

EDIT: I created a simple GitHub repo instead, to be able further explain the config file and it's fields. https://github.com/mauritzn/deno-config

mauritzn on 25 May 2020

👍4

All 3 comments

I generally want to avoid configuration - and I think people generally should not grant unrestricted access... you can do this with alias deno="deno --allow-net"

I understand there's some ergonomic issues with these flags - I'm confident we'll find ways to ease usage - but I think it's important to establish a simple security model first before dealing with ergonomic issues.