Is it wise to rely on Observable's implicitely provided hljs instance, which is a fork of Highlight.JS that's stuck at 9.12, has no public repository and uses its own tags for NPM which have no relation to HLJS?
Hmm, thanks for bringing this up. You're right that I'm probably trying too hard to avoid an extra import here. Although, I don't anticipate any particular danger with this, managing the dependency that results is also a bit awkward. Do you happen to know what other Observable notebooks that use custom syntax highlighters are doing?
Fil's notebooks use the Observable hljs instance, but falls back to manually loading it: https://observablehq.com/@fil/mdh#mdh
I checked at what point .hljs property on window is created: It happens automatically when the highlight.js is included, and there's no way to override it. Couldn't check the current version because jsdelivr.com is currently encountering some issues.
This notebook demoes Prism: https://observablehq.com/@lsei/advanced-syntax-highlighting
Nitpick: "resolve((hljs = v))" -> "resolve(hljs = v)" :)
I'd also recommend to add a comment that the md line triggers the loading of highlightjs by Observable. Otherwise it seems a bit obscure :D
Another variant that shouldn't conflict with Observable's instance is to import hljs as a module via jspm.dev:
hljs = import(`https://jspm.dev/highlight.js@10.7.2`).then(d => d.default)
Note that some organizations which use Zscaler for their security may mess up CORS access to jspm.dev.