{{ message }}
Repository navigation
Type the editor handle as Muya, from the engine's own declarations (#4257) - #5533
Merged
Merged
Conversation
`exports` points `.` at `./src/index.ts` and nothing ships built typings, so a TypeScript consumer either type-checks the whole muya tree under its own compiler options or falls back to a hand-written shim. Add a declaration-only build (`pnpm build:types`, ~4s) so consumers can resolve `lib/types` instead; `pnpm build` already emits the same directory through vite-plugin-dts. Two declaration-emit errors had to go first - both invisible to `tsc --noEmit`, which is all `lint:types` runs: - `sanitize` inferred a type naming `TrustedHTML` from a transitive `@types/trusted-types` path that cannot be referenced from outside the package (TS2883). - `loadLanguage`'s return type named the unexported `ILangLoadStatus` (TS4023). CI now runs the emit as well, so neither can come back unnoticed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e used as Both surfaced the moment a consumer type-checks `Muya.use(...)` against real typings rather than an `any` shim: - `ParagraphFrontButton` was the only UI plugin without a static `pluginName`, so the instance registry keyed it under `undefined`. Nothing reads that map by name today (destroy iterates the values), but two unnamed plugins would have evicted each other. - `ImageEditTool` declared its `options` parameter as the fully-populated `Options` while `Muya.use` hands every plugin a plain object, and the constructor merges the defaults in anyway. `Partial<Options>`, like every sibling plugin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…4257) `tsconfig.base.json` redirected the import to a hand-written `src/types/muya-core.d.ts` shim, because the package's `exports` map points at TS source and it shipped no built typings. The shim's editor surface was `[key: string]: any`, which is what kept `MuyaInstance` in editor.vue an `any` (item 2 of #4257). Now that muya emits `lib/types`, point the path there and delete the shim. `typecheck` builds those declarations first (~4s) and `postinstall` emits them too, so an editor opened straight after a clone resolves the import. Pointing the path at the source instead was the alternative, but that type-checks the whole muya tree under the desktop's compiler options - different lib/target, and its ambient globals (`Element.__MUYA_BLOCK__`, `window.MUYA_VERSION`) would have to move into the desktop's global scope, where `Window.DIRNAME` already conflicts. `skipLibCheck` keeps the built declarations from leaking muya's internals into desktop CI. `ListItem`'s index signature goes with it: `listToTree` only ever reads `lvl`/`content`/`slug`, and the signature was the one thing stopping the engine's own `ITocItem` from satisfying it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closes the last `any` alias from item 2 of #4257. `editor` becomes a `shallowRef<Muya | null>` - shallow because the instance is `markRaw`d anyway and a deep ref would map the class through `UnwrapRef`. What the real type surfaced, all of it previously unchecked: - Handlers that reach the engine from the `bus` (whose payloads are `unknown`) now cast to the engine's own parameter types rather than to nothing at all: search/replace options, the find direction, the paragraph insert location, the pre-source-mode selection, the per-tab engine history. - `sequenceTheme` is a free-form string in the preferences store but `'hand' | 'simple'` to the engine. - Four watches and four bus handlers called straight through a handle that is null until `onMounted`. - `applyCursor`'s `CursorEditor` and `getHtmlToc`'s `TocEntry` were structural stand-ins that no longer described the engine: the former declared `setCursor(cursor: unknown)`, the latter carried an index signature that the engine's `ITocItem` cannot satisfy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Website preview ready: https://pr-5533-marktext-website.ransixi.workers.dev Built from |
Contributor
|
Build artifacts for PR #5533: Run: https://github.com/marktext/marktext/actions/runs/35855046883 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finishes item 2 of #4257 — the
MuyaInstancealias that #5521 had to leave asany.Reopened from #5523, which GitHub auto-closed when its stacked base branch was
deleted on merge; same branch, rebased onto develop. CI was green there.
Why it was still
anyNot "waiting for upstream" any more:
packages/muyais in the tree, thedesktop depends on it as
workspace:*, and the realMuyaclass exposes everymember
editor.vuecalls. The blocker was type resolution.@muyajs/core'sexportsmap points.at./src/index.tsand the package ships no builttypings, so
tsconfig.base.jsonredirected the import to a hand-writtensrc/types/muya-core.d.tsshim whose editor surface was[key: string]: any.Pointing the path at the source instead was the obvious alternative, and I
measured it: 37 errors, all from muya's ambient declarations being absent from
the desktop's program. Pulling those in means merging two packages' global
scopes —
Window.DIRNAMEis already declared in both, with differentoptionality — and it makes the desktop's compiler options the ones muya's
source has to satisfy (
src/utils/prism/loadLanguage.tsalready fails underthem while passing muya's own
lint:types). So: built declarations, whichskipLibCheckkeeps at arm's length.What changed
muya — a declaration-only build (
pnpm build:types, ~4s;pnpm buildalready emits the same
lib/typesthrough vite-plugin-dts). Twodeclaration-emit errors blocked it, both invisible to
tsc --noEmit:sanitize's inferred type namedTrustedHTMLthrough a transitive@types/trusted-typespath (TS2883), andloadLanguage's return type namedthe unexported
ILangLoadStatus(TS4023). Muya CI now runs the emit.Two plugin defects surfaced the moment
Muya.use(...)was checked against realtypings:
ParagraphFrontButtonwas the only UI plugin with no staticpluginName, sothe instance registry keyed it under
undefined. Harmless today — nothingreads that map by name — but two unnamed plugins would evict each other.
ImageEditTooltyped itsoptionsparameter as the fully-populatedOptionswhileMuya.usehands every plugin a plain object; the constructormerges the defaults in anyway.
desktop —
@muyajs/coreresolves to../muya/lib/types, the shim is gone,and
editoris ashallowRef<Muya | null>(shallow: the instance ismarkRawd anyway, and a deep ref would map the class throughUnwrapRef).pnpm typecheckandpostinstallbuild the declarations first.The real type found 26 unchecked call sites:
onMountedassigns itapplyCursor'sCursorEditordeclaredsetCursor(cursor: unknown);getHtmlToc'sTocEntryandlistToTree'sListItemcarried index signatures the engine'sITocItemcannot satisfyThe
unknownpayloads now cast to the engine's own parameter types(
Parameters<Muya['search']>[1]and friends) rather than to nothing.Known gap
The Lint workflow still has
paths-ignore: packages/muya/**, so a muya-only PRthat changes the public API would not re-run the desktop typecheck. That is the
pre-existing gap; the new declaration-emit step in Muya Lint at least catches
the emit breaking.
Verification
pnpm typecheckfrom a clean tree (rm -rf packages/muya/lib) — the scriptregenerates the declarations and vue-tsc is clean.
pnpm lint— 0 errors (148 pre-existing warnings).pnpm -C packages/muya lintand
lint:typesclean.pnpm test:unit770 passed andpnpm -C packages/muya test1990 passed —both identical to the branch point (the failures in my worktree are a local
node_modulessymlink artifact).build:unpack; the built bundle wasgrepped to confirm it carries these sources.
🤖 Generated with Claude Code