Feature request: Allow passing a `config` setting in the scripts file
saadq opened this issue · comments
Deno now supports passing a --config
flag to its CLI for customizing the builtin compiler/linter/formatter with a configuration file: https://deno.land/manual@v1.16.3/getting_started/configuration_file. I tried looking through the DenoCliOptions
, but it doesn't seem like this is currently supported.
To use this, currently I have a config file:
deno.json
{
"fmt": {
"options": {
"singleQuote": true
}
}
}
velociraptor.yaml
scripts:
lint:
cmd: deno lint --config=deno.json
desc: Lints the code using Deno's standard linter
format:
cmd: deno fmt --config=deno.json
desc: Formats the code using Deno's standard formatter
It would be nice if we could specify our config file the same way we could specify files for lock
/imap
/envFile
. Perhaps something like:
velociraptor.yaml
configFile: deno.json
scripts:
lint:
cmd: deno lint
desc: Lints the code using Deno's standard linter
format:
cmd: deno fmt
desc: Formats the code using Deno's standard formatter
I'd actually like to have a similiar feature but in reverse.
Since deno already lookup automatically for deno.json
as a config file, it would also be nice to allow specifying velociraptor config within the same deno.json
to only have a single config file for both scripts and deno (a bit like package.json
actually)
Hey @saadq and @lowlighter, thanks for your proposals 🙂
Vr's support for Deno CLI options needs to be aligned with the new versions. There is some work in progress (see #95) which includes supporting the --config
option.
As for the unified config file: that's a nice idea. Here are a couple of thoughts:
- many vr options can be specified at top-level (outside of the
scripts
object). This has potentially the risk of colliding with future Deno config options but could be mitigated by moving all vr options under avr/velociraptor
property:{ "compilerOptions": { ... }, "velociraptor": { "allow": [...] "scripts": {...} } }
- the number of vr's config file names and formats is growing rapidly: this will inevitably have negative effects on #90 because of the number of network requests to get to the right file. I don't think that adding two more (
deno.{json,jsonc}
) will have a huge impact. We have to consider the possibility of Deno adding more formats though. We can always exclude these last config files from the remote resolving but it feels unfair to users that would like to use that format.
PS Apologies for the late response
Thanks for the reply, I missed that other issue. Closing in favor of #95