The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.
The only flag for which it has special treatment is `--config`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.
The only flag for which it has special treatment is `--config`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.
The only flag for which it has special treatment is `--config`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.
The only flag for which it has special treatment is `--config`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does not attempt to handle full bourne-shell quoting semantics.
It will only handle quotes around the entire flag, e.g.
"--foo=some value" or around the flag value, e.g. --foo="some value"

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags and whether or not
the accept a value would be prohibitively difficult to maintain without
some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

The main purpose here is really to prevent vscode from autodetecting
.bazelrc as a shell file, resulting in complaints about syntax that
isn't valid in a bash script, or mistakenly highlighting e.g. variable
expansions as if they were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of
e.g. config specifiers and so on.

This does not attempt to handle full bourne-shell quoting semantics.
It will only handle quotes around the entire flag, e.g.
"--foo=some value" or around the flag value, e.g. --foo="some value"

This does _not_ try to exhaustively match the list of all possible
flags, and so it can make mistakes like treating --copt -O3 as if it
were two separate flags rather than a flag + value, however that's
mostly harmless.  Maintaining a list of known flags and whether or not
the accept a value would be prohibitively difficult to maintain without
some kind of automation.

There is special treatment for a couple of flags, including
`--config` and a few flags that expect regex arguments, like
`--instrumentation_filter`.

Closes bazelbuild#259

feat: syntax highlighting for .bazelrc

The main purpose here is really to prevent vscode from autodetecting .bazelrc
as a shell file, resulting in complaints about syntax that isn't valid in a
bash script, or mistakenly highlighting e.g. variable expansions as if they
were actually honored in a .bazelrc.

We can also do a bit better, by actually understanding the semantics of e.g.
config specifiers and so on.

This does not attempt to handle full bourne-shell quoting semantics. It will
only handle quotes around the entire flag, e.g. "--foo=some value" or around
the flag value, e.g. --foo="some value"

This does _not_ try to exhaustively match the list of all possible flags, and
so it can make mistakes like treating --copt -O3 as if it were two separate
flags rather than a flag + value, however that's mostly harmless.  Maintaining
a list of known flags and whether or not the accept a value would be
prohibitively difficult to maintain without some kind of automation.

There is special treatment for a couple of flags, including `--config` and a
few flags that expect regex arguments, like `--instrumentation_filter`.

The grammar is written in YAML and compiled using `js-yaml` as part of the
build process. This requires promoting js-yaml (which was already a transitive
dependency) to a direct dev dependency, and adding a line to build.sh to do the
conversion.

YAML is easier to work with for a number of reasons, especially because
(depending on string style used) you don't need to json-escape strings, which
is especially helpful for regexes.  It also tends to version-control better,
and permits adding comments.

For testing the bazelrc grammar, this commit adds snapshot test.

Closes #259