Rename plugin to include "vitepress" in it's name

[BoussonKarel]

Now it's a bit unclear what this plugin does, people might think this plugin is for using ember in vite.

Also people wanting to use Ember in vitepress might not find it.

I would suggest something like vite-plugin-ember-vitepress

[aklkv]

Thanks for raising this @BoussonKarel, and apologies for the long reply — I wanted to actually research the ecosystem convention before answering rather than guess.

You raised two distinct concerns:

1. Unclear what the plugin does — the current name (vite-plugin-ember) sets a slightly wrong expectation that this is "Ember in Vite, generally."
2. Discoverability — people searching for "VitePress + Ember" don't find this.

Both are real. Below is how I'm planning to address each.

---

Immediate (v0.5.2, this week)

Don't rename. Address both concerns cheaply via #65:

• Expand the npm keywords from 7 to 17, adding the terms VitePress users actually search for: vitepress-plugin, emberjs, ember-source, ember-modifier, glimmer-component, template-tag, documentation, live-preview, playground, etc. This fixes most of the discoverability complaint at zero cost to existing consumers — npm search and Google both index keywords.
• Sharpen the package.json description to lead with "VitePress plugin" and mention .gjs/.gts-in-markdown explicitly.
• Add an explicit "Is this for me?" section near the top of the README that answers the three obvious questions:
  • ✅ Using VitePress — yes, this is for you
  • ☑️ Plain Vite — yes-ish, the core .gjs/.gts transform and resolver work standalone
  • ❌ Building a full Ember app with Vite (ember-cli / @embroider/vite replacement) — no, that's not this plugin's goal

Next major (v1.0.0)

Rename to vitepress-plugin-ember. I researched how published vitepress-plugin-* packages actually wire into VitePress, and your suggestion lines up with a real ecosystem convention:

Package	How it integrates	Is it a Vite plugin?
vitepress-plugin-tabs	markdown.config(md) + enhanceApp Vue component	No, pure VitePress
vitepress-plugin-mermaid	withMermaid(defineConfig) wrapper	No, config wrapper
vitepress-plugin-search	SearchPlugin() pushed into vite.plugins	Yes, it's a Vite plugin

The shared thread is "this package only makes sense inside VitePress" — not "this hooks into a VitePress-specific plugin API" (there really isn't one). vitepress-plugin-search is literally a Vite plugin published under the vitepress-plugin-* name because that's where its audience is. We match that pattern (we ship a Vite plugin, a setupEmber defineConfig-style helper, AND an emberFence markdown-it plugin — all three surfaces those packages cover).

So vitepress-plugin-ember is more accurate than vite-plugin-ember-vitepress (which doesn't match any convention, and reads awkwardly), and it's on-convention with the broader VitePress plugin ecosystem. Good suggestion.

Why I want to defer to v1.0.0 rather than do it now:

• Renaming a published npm package is genuinely expensive — every consumer updates package.json + imports, old links accumulate, npm has no clean redirect, and we just landed real users on v0.5.x.
• The discoverability complaint may be fully resolved by the keyword expansion alone — let's see before burning the rename budget.
• A v1.0.0 release is a clean place to bundle the rename together with the API stability commitment, deprecate the old name with a single intentional break, and ship a shim at vite-plugin-ember@1.0.0 that re-exports everything from the new name with a one-time runtime warning, so existing installs keep working.

Tracking the rename here so it's not lost. If after v0.5.2 the discoverability complaint persists, I'll bring v1.0.0 forward.