Implementing a ProseMirror Remark plugin - How to work with non-unist, non-string inputs?

[smoores-dev]

Howdy! I do a lot of work with ProseMirror, a rich text editing library. Recently I've been working with some folks that are interested in serializing ProseMirror documents to Markdown, and I love the unified/remark stack for working with Markdown.

I started by working out a basic remark plugin that converts mdast to a ProseMirror node tree (you can see that here: https://github.com/handlewithcarecollective/remark-prosemirror). I used the CompileResultMap interface to add a new result type for ProseMirror docs:

declare module "unified" {
  interface CompileResultMap {
    PmNode: PmNode;
  }
}

Which is awesome, I really appreciate how extensible this is. Now I'm trying to go in the opposite direction, from ProseMirror nodes to mdast/Markdown, and I'm not sure what the correct way to model that is.

What I want to be able to do is just the inverse operation: tell unified to start with a ProseMirror node and output a markdown vFile. This doesn't really seem to align with unified's processing model, though. ProseMirror nodes have already been "parsed" from the DOM, so processor.parse (which takes only a string or byte array) doesn't really work or make sense, and processor.run takes a unist tree. ProseMirror docs are structured similarly to unist trees, but don't actually implement the interface.

It seems like the move here is to produce a unist-compatible ProseMirror syntax-tree, convert the ProseMirror doc to that tree, and then processor.run on the tree to convert it to mdast and stringify to Markdown.

Does that seem right? Or am I missing something about how to handle situations like this? It seems like comparable plugins like rehype-react are essentially one way; they don't have a way to get from the CompileResult back to on AST.

[ChristianMurphy]

This doesn't really seem to align with unified's processing model, though

Unified has several different approaches to being used.
You appear to be referring mostly to the programmatic Node/JS API.
The string requirement comes in because it also has a CLI that expects to be able to read a file.

https://unifiedjs.com/learn/

---

It seems like the move here is to produce a unist-compatible ProseMirror syntax-tree, convert the ProseMirror doc to that tree, and then processor.run on the tree to convert it to mdast and stringify to Markdown.

Exactly
I'd recommend creating an mdast util, there may be some inspiration to draw from a now deprecated quill connector https://github.com/syntax-tree/mdast-util-from-quill-delta

---

ProseMirror nodes have already been "parsed" from the DOM, so processor.parse (which takes only a string or byte array) doesn't really work or make sense, and processor.run takes a unist tree. ProseMirror docs are structured similarly to unist trees, but don't actually implement the interface.

I'd recommend using unified.run if you choose to use the unified abstraction at all.
It is fine to leverage the mdast utils directly too.

[ChristianMurphy]

as the prettier docs don't recommend using the eslint plugin!

I'm aware, and disagree 😅
The complexity of running several tools more than having one config, and having all the rules in eslint I've found creates less conficts when some eslint plugins do some stylistic rules as well.

I'll take a look at switching to corepack (it's just kind of a pain to get working with Nix haha)

Hopefully corepack gets smoother with nix.
I'll also note that, with the most recent versions of npm they are often faster and just as feature rich as yarn

[smoores-dev]

Re: the plugin type -- part of the issue seems to be that the Plugin type doesn't actually pass its type parameters through to the Processor type. So it doesn't matter that I'm saying this is a Plugin that takes an MdastRoot and compiles to a PmNode, because it's then typed as a Processor that takes a unist Node, because that's the default type value. I suspect that this is the actual issue -- separately, it seems like the Typescript integration in VS Code has a bug when there are naming conflicts like this, and thinks that the Node type that compile takes as an arg is the prosemirror-model Node, but it's actually the unist Node, and it's linking me to the wrong place!

[smoores-dev]

Yup, confirmed that it's not a PmNode, it's a unist node, and VS Code/Typescript/tsserver is just linking me to the wrong Node type. This is better, but still has a cast:

export const remarkProseMirror: Plugin<[Options], MdastRoot, PmNode> =
  function (options: Options) {
    this.compiler = function (tree) {
      return toProseMirror(tree as MdastRoot, options);
    };
  };

[ChristianMurphy]

/cc @remcohaszing and @wooorm who may have other ideas on how to transition between node types with TS typings

[wooorm]

Options are perhaps optional, so that would be: Plugin<[(Options | null | undefined)?], MdastRoot, PmNode> and (options?: Options | null | undefined).

To type your custom outputs, register it:

unified/lib/index.js

Line 13 in 6838c70

* {@linkcode CompileResultMap}.

See e.g. https://github.com/rehypejs/rehype-react/blob/93fac074e8e3447088ed2408282e9e089ea7b36c/index.d.ts#L42