contentful/rich-text: the libraries behind Contentful Rich Text

Why a structured field needs a library

The readme describes the repository as a monorepo with TypeScript libraries for handling and rendering Contentful Rich Text documents, and the package list is the substance of it.

The reason a whole set of libraries exists is worth stating. A Rich Text document is a tree of typed nodes: paragraphs, headings, lists, links, embedded entries and assets, with marks such as bold and italic applied to ranges of text. It is not HTML, and that is the point. Because the structure is preserved rather than flattened into a string, an application can render the same document in different ways, style it for its own design, and extract information from it.

But every consumer still has to do that work, and the work is the same for everybody. The libraries in this repository are that work, already done and already tested, and they are split by what they do rather than by what they are called.

The release history shows how the split has grown. The three most recent releases are the markdown converter, the HTML renderer, and the type definitions package, and they are all in the high teens by version. That is the shape of a set of packages that started as one and became several, each with its own version, its own release cadence, and its own consumers.

The licence is MIT, the primary language is TypeScript, and the last push was on 2026-10-18.

The official packages, one per conversion

The package list is organised into two groups, and the first one is the set the project maintains.

The converter from markdown produces a Rich Text document from a markdown document, and the direction matters: this is the package you use when you are importing existing content into the content platform, not when you are displaying it. That is a less common need than rendering, and it is the package that makes a migration possible, because most existing content is in markdown.

The HTML renderer goes the other way and converts a Rich Text document into HTML, which is the package you want when you are rendering on the server, into an email, or into a static page. The plain text renderer does the same thing without the markup, and it is the one people forget they need: a search index, a text summary, a social card, and an accessibility fallback all want plain text, and reconstructing it from the rendered HTML is a waste of everyone's time.

The link utilities are the fourth official package, and they do something different: they extract the entity links, meaning the entries and the assets that the document references, and resolving those links is a problem that every application has to solve separately, usually by walking the document tree and collecting identifiers as it goes.

And then there is the package of type definitions and constants for the field type itself. This is the one that everything else depends on, because it is the contract: the node types, the mark types, and the shape of the document. A library that renders Rich Text is only possible because the format is written down, and the format being written down in a package is what stops every implementation from inventing its own interpretation.

The deprecated package in the list is the React one for a static site generator, and it is marked as deprecated with a link to a specific commit rather than to the current tree. Pinning the documentation of a deprecated package to a commit is the correct thing to do, because a moving link would change what the documentation says underneath the reader.

The React renderer and the community alternatives

The official list ends with the React renderer, which parses a Rich Text document into React components. And then the second group, the community made packages, is the more interesting list for a reader deciding what to use.

There is an opinionated JSX renderer by a third party, and the word opinionated is doing the work. The official React renderer is the neutral one, and it will produce elements for every node type in the document with whatever the document says. An opinionated renderer makes choices: how a heading looks, whether a link is a link component, how an embedded entry is laid out. For a project with a design system, that is the package you want, because the opinionated renderer is where the design lives.

Then there are three renderers for other frameworks, and the descriptions carry the information that matters. One is a Flutter renderer, marked as work in progress. One is an Angular renderer. And the third is the JavaScript one for the server side, whose name follows the usual convention of prefixing the framework.

So the coverage across frameworks is uneven, and the readme is honest about which ones are finished. What is interesting is that the framework gap is being filled by the community rather than by the vendor, which is a reasonable division of labour for a format specification: the vendor ships the specification and the most widely used renderer, and everybody else fills in the rest.

The readme then links the concept documentation, the getting started tutorial, and a migration guide for moving existing content to the Rich Text field type. That last one is the piece that tells you this repository exists in the context of a real migration, and the two libraries in the official list that handle the boundaries of the format, the markdown converter and the link utilities, are the two you need for that job.

The get involved section asks for pull requests, and the reach out section splits the support routes by kind of question: a community forum for how to use the library, a chat channel, an issue tracker for bugs and features with a reminder to remove credentials from anything you share, and a support ticket for anything involving confidential information. That last split is a good sign, because it says the public channels are for public questions.

The build system, and what it says about scale

The package manifest is the interesting file, because a monorepo's manifest is where its conventions live.

The root package is private and named for the whole collection, with a description saying it is a monorepo for all the packages related to Rich Text. The workspace definition is a single glob over the packages directory.

  "workspaces": [
    "packages/*"
  ]

And the build is driven by a task runner that runs a target across every project at once. There is a command to build everything, one to clean the build output and the installed dependencies, one to lint, and one to test, and each of them fans out across the workspace. That is the standard arrangement for a monorepo of this size: one command for the whole tree, and the per-package scripts underneath it.

The individual tools are worth naming because they are a snapshot of a moment. The bundler is Rollup with plugins for the module resolution, for the JSON imports, and for a fast compiler. The compiler itself is the native TypeScript transform, and the type checker is the native preview of the TypeScript compiler, which is the experimental path. The test runner is Jest with a shared base configuration file, and there is a transform for it too. The formatting is Prettier, and the linting is ESLint with the typescript parser and a plugin set that includes a rule for accessibility in JSX, one for the hooks, one for the import helpers, and a couple of others.

That last list is the interesting one for a content rendering library, because a rendering library is exactly the kind of code where an accessibility rule has teeth. A rich text renderer decides what a heading, a list, and a link are in the output document, and an accessibility lint on the JSX it produces is a check on the output rather than on the input.

There is also a commit message convention enforced with a tool, a file watcher integration for the pre-commit hook, a dependency update configuration, and an architecture document in the repository root. The architecture document is a good sign for a project with this many packages, because the thing that goes wrong in a monorepo of libraries is that nobody can say which package owns which responsibility.

The node version floor is the other detail worth noting, and it is a recent one, which tells you the packages are built and tested against a current runtime rather than an old one.

Editorial conclusion

contentful/rich-text fits a developer whose content comes from Contentful as Rich Text and who needs a renderer or a converter for it, and it fits a team that wants the conversion logic in a tested library rather than in the application. It does not fit a project whose content is stored as markdown, since the markdown converter goes the other way. Verify first which package you actually need, because there are several and they are not interchangeable, and whether the community renderer for your framework is maintained, since the official ones cover React and the rest are listed as community work.

Frequently asked questions

Official sources

1. contentful/rich-text on GitHub
2. Issues
3. License: MIT
4. README
5. Releases