add noderc proposal #225
add noderc proposal #225
Conversation
| } | ||
| ``` | ||
|
|
||
| Open question: how should we handle override v.s. concatenation? Should we invent a special syntax? For example, to concatenate, use `"+import"`, otherwise, use `"import"`? Or is that too cryptic and we should just do "override if it's not an array, concatenate if it's an array?" |
There was a problem hiding this comment.
If "extend" field is an array, meaning it can extend multiple files, I think its important to allow more granular configuration to chose which extend and which override.
This could be achieved by
{
"extend" : [{
"alias": "foo",
"path": "./.noderc.foo.json"
}, "./.noderc.bar.json"],
"import": [{ "alias": "foo" }, "amaro/register"]
}This could allow to esplicitly estend foo and override others. (Bikeshed on naming etc...)
There was a problem hiding this comment.
What is the alias field specifying here? Is it some kind of variable-like thing?
We could also just provide "override" either as a different array, or do a filtering of configs in extend (or both?).
"extends": [{ "filter": ["import"], "path": "./.noderc.foo.json" }]
| } | ||
| ``` | ||
|
|
||
| The general naming convention of the configuration keys are snake-cased version of corresponding CLI flags (if any) without the `--` prefix, or lower-cased version of corresponding environment variables (if any). This allows easier conversions. Exceptions include configurations that are grouped by common prefixes, for example: |
There was a problem hiding this comment.
I'm confused. The CLI has a parameter named --watch-path. What is the expected key name for it int he configuration file?
watch-path(kebab case)watch_path(snake case)
There was a problem hiding this comment.
Basically, "snaked-cased version" should be "kebab-cased version".
|
|
||
| Open question: when both the escape hatches and the structural representations are specified, which one should take precedence? | ||
|
|
||
| ### Overriding the noderc file being applied |
There was a problem hiding this comment.
Can we have a simple section that details the precedence of definitions? See https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html#precedence-categories for an example.
This is consolidating the ideas from nodejs/node#53787 so far.
Refs: nodejs/node#53787