Org-wide npm naming convention for published packages

[cailmdaley]

Context

We're hitting a decision point in lightcone-ui that wants org-level alignment before we publish anything new.

lightcone-ui is moving toward a React renderer + theme architecture (see vellum-reader/myst-as-ast-layer-for-lightcone-ui/lightcone-ui-react-port for the design fiber). That adds ~5 new npm packages to the workspace: renderer, providers, styles, plus theme apps. Before publishing those, we want to lock a naming convention that the whole org agrees on, so we don't ship a mishmash that's painful to renormalize later.

Current state of org packages

Package	Repo	Name on npm	Status
mystra	LightconeResearch/MySTRA	mystra (unscoped)	Published
lightcone-ui-core	LightconeResearch/lightcone-ui	lightcone-ui-core	publishConfig:public, not yet published
lightcone-ui-cli	LightconeResearch/lightcone-ui	lightcone-ui-cli	not published
astra-spec	LightconeResearch/astra-spec	(TS bindings package planned, see astra-spec issue #TBD)	not yet
Future: lightcone-cli (formerly Prism), Prism-UI, lightcone-ui new packages	various	unset	unpublished

Proposal

Adopt @lightcone/* as the npm org scope for everything published from LightconeResearch/. Concretely:

• New packages: @lightcone/core, @lightcone/cli, @lightcone/renderer, @lightcone/providers, @lightcone/styles, @lightcone/mystra, @lightcone/astra-spec, etc.
• Existing renames:
  • lightcone-ui-core → @lightcone/core
  • lightcone-ui-cli → @lightcone/cli
  • mystra → @lightcone/mystra (breaking change for any downstream consumers; mystra is small enough today that this is feasible)

Why scoped

• Discoverable: anyone seeing @lightcone/... in a package.json knows where it came from.
• Prevents name collisions with unrelated unscoped packages (e.g., the existing mystra name space could collide with anything else).
• Matches MyST convention (@myst-theme/providers, @myst-theme/site, etc.) — the ecosystem we're integrating with does this.
• Extensible: future packages don't need to negotiate unique unscoped names.

Why not

• Breaking change for mystra — any external consumer pinning mystra would need to migrate. (As of today: vellum is the only known consumer, and it's internal.)
• Migration cost for any docs / READMEs / install instructions referencing the old names.
• Slight verbosity in import paths (@lightcone/core vs lightcone-core).

Questions for the org

1. Adopt @lightcone/* for new packages? (Lowest-stakes question — uncontroversial assuming yes.)
2. Rename mystra to @lightcone/mystra? Breaking change. Worth doing while the consumer base is small (= now).
3. Migrate lightcone-ui-core → @lightcone/core before first publish? No external consumers yet (publishConfig set but never pushed). Free rename window.
4. Edge cases:
   • lightcone-cli (the agentic CLI, formerly Prism) — @lightcone/cli collides with lightcone-ui-cli's migration target. Resolve by reserving @lightcone/cli for the agentic CLI and using @lightcone/ui-cli or @lightcone/lc-ui for the UI CLI?
   • VS Code extension — marketplace has its own naming (publisher.name); npm scope is irrelevant for the extension itself.
   • Python packages (e.g., astra CLI on PyPI) — separate ecosystem, separate decision.

Asking / FYI

@EiffL @lhparker1 — would value your inputs on this. Particularly on the mystra rename (Francois) and the @lightcone/cli collision (Liam, since you're touching CLI shapes from both sides).

The forcing function on timing: I'd like to settle this within the next few weeks so the lightcone-ui React renderer work can publish under stable names. Not urgent today; urgent before first npm publish of the new packages.