recognize _brand.ya?ml as part of a Quarto project

[cscheid]

This closes #483.

It requires quarto-dev/quarto-cli#11006 to be merged for it to work.

There's also an issue we haven't had to deal with before, which is how should different versions of the extension interact with different versions of quarto-cli. Right now, if the extension is "too new" for the cli, _brand.yml will be validated as if it were _quarto.yml or _metadata.yml. Not horrible, but not ideal. I wonder if we have a mechanism for addressing this.

[cscheid]

@juliasilge Nothing too special here, but I wanted to flag that versioning issue I brought up above as something we eventually need to sort out company-wide.

[juliasilge]

I may be misunderstanding the particulars of the versioning, but is it possible to check the cli version and gate the new extension behavior on new-enough cli? Like this:

quarto/apps/vscode/src/providers/preview/preview.ts

Line 487 in 20fb64c

if (semver.gte(this.quartoContext_.version, rPkgRequiredVersion)) {

[cscheid]

I was thinking more generally about what to do when Posit's product releases don't quite align; is there something we can do as a company to avoid this kind of code? I imagine it'll make everyone's codebases that much more annoying to test.

Nevertheless, yes: right now I should use precisely QuartoContext.version. Thanks!

[juliasilge]

is there something we can do as a company to avoid this kind of code?

For tools inside of one ecosystem (R packages, Python packages, etc) there are of course native tools to manage these kinds of version dependencies. It's an interesting question for cross-ecosystem tooling!