feat: Allow post-id only by using profile from metadata

[gadenbuie]

Part 2 of addressing the changes described in this comment.

I've also implemented a change where you can put your profile in _quarto.yml or the post metadata

bluesky-comments:
  # profile: did:plc:fgeozid7uyx2lfz3yo7zvm3b
  profile: coatless.bsky.social

and then use the post ID directly in the shortcode

{{< bluesky-comments 3lbtwdydxrk26 >}}

This would make it easier to a) globally change the profile name or b) lookup your DID once and never have to do it again.

This PR also adds a set of unlisted tests to docs/ that can be viewed at {site-preview}/tests. The goal is to have a set of pages for quick manual checks (that we might automate at some point).

[coatless]

that can be viewed at {site-preview}/tests.

We potentially might want to mirror the main Quarto approach for tests, e.g. tests/ as a top-level directory added to .quartoignore using Deno.test() framework.

@cderv were there ever any notes on best practices for testing Quarto extensions outside of the tests/ README in the main repo?

https://github.com/quarto-dev/quarto-cli/tree/main/tests

[cderv]

were there ever any notes on best practices for testing Quarto extensions outside of the tests/ README in the main repo?

No there is not yet for extension. tests/ folder in quarto-cli is mainly for test of Quarto itself, not extension. We use deno test because quarto uses deno, but you are not tied to this framework.

I would say it depends here what you want to test.

Testing quarto with this extension

• It could be done either in this repo, using any test framework that allows to look at some html output with DOM inspection, or html output in browser (like playwright). You would install latest quarto, and then run you render test. Using playwright it an option here: easy to set up for test, and has some infrastructure to help test HTML outputs.

  • Some of our tests in quarto-cli are using playwright. This is when need to test the output when document is opened in the browser, and so when inspecting output file content is not enough.
  • Those tests in Quarto using playwright are not using Deno test. They are separate.

• It could be done in quarto itself by providing some new test cases to add for extension. This is something we have discussed like

  • a repo provide some content for us to test
  • we add this content to our regular quarto render test and if there is an error we report upstream.

This is easy to do in this repo so maybe the latter is too much yet.

Testing your extension lua code

• This is closer to what could be called unit test. You would test your Lua processing directly. This also could be done using some framework that allows to test Lua or snapshot text content.

• Testing lua can be done with https://github.com/bluebird75/luaunit. It is standalone and can be included in the project, then Lua would need to be run on it. quarto pandoc lua maybe enough to run with same lua version as pandoc

• Testing Lua filter could also be done with Pandoc context in mind (native or other output). Example in pandoc lua filter repo : https://github.com/pandoc/lua-filters/tree/master/pandoc-quotes.lua

  • The logic is similar to what I described:
    • It uses simple document to produce simple output with pandoc
    • And it uses diff to see what as changed.

So as you see there is not yet one way, and I have given thought about it. So we could also start comming up with some advice and nice helper for that.

Hope it helps

[gadenbuie]

My thinking was that eventually we could use playwright for client-side testing. For now, keeping the test cases in the docs site is a cheap suite of smoke tests in that we'll get CI failures if the docs site fails to build. It's also easy for manual verification since the tests are deployed with the docs (and in a way serves as additional examples).

For stuff that is supposed to break with a quarto render, or for testing in a project context, we'd need to use tests/. I'd be very interested in any tools Quarto provides to help with testing, but I also think that simple, minimal overhead tests are the best approach for right now.