Replace the link of `rehype-shiki` plugin with the official one

[logica0419]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything (or linked relevant results below)

Problem

Currently, the suggested plugin for Shiki integration is https://github.com/rsclarke/rehype-shiki.
However, it has not been upgraded for 5 years, so it shouldn't be displayed here.
https://github.com/rehypejs/rehype/blob/main/doc/plugins.md#list-of-plugins

Current solutions

No current solutions

Proposed solutions

Shiki has its official implementation https://shiki.matsu.io/packages/rehype, so I guess replacing the link with this one is better.

However, it's in the Shiki monorepo https://github.com/shikijs/shiki/tree/main/packages/rehype, so they don't

• pick a name prefixed by rehype-
• have rehype-plugin in their package.json (this can be solved easily)
• have rehype-plugin in their repo tags

I wonder if it's OK to list this plugin on the page.

[wooorm]

Hmm, it is a bit unfortunate, that the package name is @shikijs/rehype instead of say @shikijs/rehype-shiki. I dunno. Perhaps @remcohaszing or @ChristianMurphy have opinions.

[JounQin]

I think @foo/rehype is a good name for foo by the way.

[remcohaszing]

I like the name @someintegration/rehype. But more importantly, I don’t think this is up to us.

I do think it’s good to recommend an official integration over a third party one (given it’s maintained).

[wooorm]

While organizations on npm are sometimes used for one single specific tool such as here, they are often used for companies/organizations/persons that have different things: @google/rehype-descriptive-name. Or, think, @wooorm/rehype-highlight, being my own fork.

This is also supported in load-plugin/unified-engine/etc: you can pass preset-wooorm to load remark-preset-wooorm, and also pass @wooorm/preset to load @wooorm/remark-preset.

[JounQin]

So load-plugin will prefer @shikijs/rehype-rehype for @shikijs/rehype? Maybe we should support @org/<pluginName> suffix in load-plugin?

[wooorm]

Maybe we should support @org/<pluginName> suffix in load-plugin?

What do you mean? If passed @x/y, what is the value that you suggest to load?

People can pass @x/y and it will load @x/y.

I am not sure. It has been documented for 10 years that people should use a prefix (rehype-). And only use that prefix if it is indeed a plugin.

I think the first important thing is that there is a contract on how plugins are named.
Then, from that, scopes do not change that contract

So load-plugin will prefer @shikijs/rehype-rehype for @shikijs/rehype?

No, it should not do that. But, people should also not call things that.

[JounQin]

@wooorm

So using @shikijs/rehype will try load @shikijs/rehype first and fallback to @shikijs/rehype-rehype if the the previous one is not installed, right? Then there should be no issue at all? No one can publish a package named @shikijs/rehype-rehype except the @shikijs team themselves.

cc @antfu

[remcohaszing]

@JounQin You misread as @shikijs/rehype-shiki as @shikijs/rehype-rehype.

[JounQin]

@JounQin You misread as @shikijs/rehype-shiki as @shikijs/rehype-rehype.

@remcohaszing

I didn't, I'm trying to talk about the possible loading logic when @shikijs/rehype is not installed but specific in rehypePlugins for example.

[wooorm]

Then there should be no issue at all

There is indeed currently no problem: people can use this package.

From your “Maybe we should support @org/<pluginName> suffix in load-plugin?”, I was wondering whether you proposed shikijs -> @shikijs/rehype, which I do not really think is a good idea.

[JounQin]

I was wondering whether you proposed shikijs -> @shikijs/rehype, which I do not really think is a good idea.

I wasn't, but afrer thinking, @shikijs -> @shikijs/rehype can be considered?