agent_coder
f555fc87da
Move every SERVER Markdown->ProseMirror path off the editor-ext markdown layer (`markdownToHtml`, a second marked-based parser) onto the canonical `@docmost/prosemirror-markdown` package, and add a foreign-markdown normalizer at the import boundary. Code: - `ImportService.processMarkdown` (single `.md` upload) now parses `markdownToProseMirror(normalizeForeignMarkdown(md))` directly — no HTML hop. - `PageService.parseProsemirrorContent` markdown case (page create/update with `format: 'markdown'`) same. - `FileImportTaskService` (zip import) parses markdown with the package, then serializes to HTML (`jsonToHtml`) so the SHARED HTML attachment / internal-link pipeline (processAttachments + formatImportHtml + processHTML) keeps handling `.md` and `.html` imports uniformly. The markdown PARSE — the drift source — no longer goes through editor-ext; the PM->HTML->PM hop that follows is lossless plumbing for attachment resolution, not a second parse. - `canonicalizeFootnotes` stays as an idempotent #228 safety net for the HTML path (a no-op on the already-canonical markdown output). Normalizer (`integrations/import/utils/foreign-markdown.ts`): a TEXT pre-pass, NOT a parser fork. The strict canonical parser does not accept GFM `[^id]` reference footnotes (and would misread `[^id]: def` as a CommonMark link-ref definition, silently corrupting the ref into a bogus link), so the normalizer rewrites reference footnotes into canonical inline `^[def]` before parsing. Callout surfaces (`:::type` and `> [!type]`) are intentionally NOT touched — the canonical parser already accepts BOTH natively, so normalizing them would be redundant and risk degrading its nesting/code-fence-aware handling. Fixtures-first: foreign-markdown.spec pins the normalizer and the end-to-end acceptance (no literal `[^id]`/`:::` leaks; re-export is canonical). The two footnote-canonicalize specs are updated to the canonical output — the parser assigns fresh `fn-*` ids, so they now assert by definition BODY order (still reference-ordered, deduped, orphan-free). FINAL CHECK: `grep -rn "htmlToMarkdown\|markdownToHtml" apps/server/src` (non -test) is now empty — both editor-ext markdown-layer functions are gone from the server. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
24 lines
1.1 KiB
JavaScript
24 lines
1.1 KiB
JavaScript
// Jest stub for @tiptap/react.
|
|
//
|
|
// The server export/import code paths transitively import editor-ext, whose node
|
|
// extensions import from `@tiptap/react`. The real module re-exports all of
|
|
// `@tiptap/core` (headless, safe under node) AND adds React view helpers
|
|
// (`ReactNodeViewRenderer`, …) that eagerly pull in react-dom — which throws
|
|
// `navigator is not defined` under jest's node environment.
|
|
//
|
|
// So this stub DELEGATES to the real `@tiptap/core` (keeping `mergeAttributes`,
|
|
// `Node`, `Mark`, `nodeInputRule`, … working — they are used by
|
|
// `jsonToHtml`/`htmlToJson` on the server) and overrides ONLY the React view
|
|
// helpers with no-ops. Those helpers are referenced solely inside `addNodeView()`
|
|
// — code that runs only in a live browser editor, never on the server; if any
|
|
// were actually invoked here it would (correctly) surface as a test failure.
|
|
const core = require('@tiptap/core');
|
|
|
|
module.exports = {
|
|
...core,
|
|
ReactNodeViewRenderer: () => () => ({}),
|
|
NodeViewWrapper: () => null,
|
|
NodeViewContent: () => null,
|
|
ReactRenderer: class {},
|
|
};
|