Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
The unified npm package is an interface for parsing, inspecting, transforming, and serializing content through syntax trees. It is built on the concept of syntax trees and is often used to work with content in markdown, HTML, and plain text formats. Unified is part of the unified collective which provides a range of plugins and utilities for content processing.
Parsing Markdown to Syntax Trees
This feature allows you to parse Markdown content into an abstract syntax tree (AST) using the remark-parse plugin.
const unified = require('unified');
const markdown = require('remark-parse');
const processor = unified().use(markdown);
const tree = processor.parse('# Hello world');
console.log(tree);
Transforming Syntax Trees
This feature demonstrates transforming a Markdown AST to an HTML AST and then serializing it to an HTML string.
const unified = require('unified');
const markdown = require('remark-parse');
const remark2rehype = require('remark-rehype');
const html = require('rehype-stringify');
const processor = unified()
.use(markdown)
.use(remark2rehype)
.use(html);
const file = processor.processSync('# Hello world');
console.log(String(file));
Linting and Validating Markdown
This feature shows how to use unified with remark-lint to lint and validate Markdown content.
const unified = require('unified');
const markdown = require('remark-parse');
const remarkLint = require('remark-lint');
const processor = unified()
.use(markdown)
.use(remarkLint);
processor.process('# Hello world', function (err, file) {
console.error(report(err || file));
});
Compiling Markdown to HTML
This feature illustrates compiling Markdown to a fully formatted HTML document.
const unified = require('unified');
const markdown = require('remark-parse');
const remark2rehype = require('remark-rehype');
const doc = require('rehype-document');
const format = require('rehype-format');
const html = require('rehype-stringify');
const processor = unified()
.use(markdown)
.use(remark2rehype)
.use(doc)
.use(format)
.use(html);
const file = processor.processSync('# Hello world');
console.log(String(file));
markdown-it is a Markdown parser with a focus on speed and extensibility. It is similar to unified in that it can parse and render Markdown, but it does not use an AST or provide the same plugin ecosystem.
remarkable is another Markdown parser and renderer. It offers a similar feature set to markdown-it but also does not use an AST or have the extensive plugin system that unified offers.
showdown is a JavaScript Markdown to HTML converter. It is similar to unified in that it converts Markdown to HTML, but it does not provide a unified interface for parsing, transforming, and serializing content.
unified lets you inspect and transform content with plugins.
processor()
processor.compiler
processor.data([key[, value]])
processor.freeze()
processor.parse(file)
processor.parser
processor.process(file[, done])
processor.processSync(file)
processor.run(tree[, file][, done])
processor.runSync(tree[, file])
processor.stringify(tree[, file])
processor.use(plugin[, options])
CompileResultMap
CompileResults
Compiler
Data
Parser
Pluggable
PluggableList
Plugin
PluginTuple
Preset
ProcessCallback
Processor
RunCallback
Settings
TransformCallback
Transformer
unified is two things:
unified
(this project) is the core package, used in 1.3m+ projects on GH,
to process content with pluginsSeveral ecosystems are built on unified around different kinds of content. Notably, remark (markdown), rehype (HTML), and retext (natural language). These ecosystems can be connected together.
unifiedjs.com
In some cases, you are already using unified.
For example, itโs used in MDX, Gatsby, Docusaurus, etc.
In those cases, you donโt need to add unified
yourself but you can include
plugins into those projects.
But the real fun (for some) is to get your hands dirty and work with syntax trees and build with it yourself. You can create those projects, or things like Prettier, or your own site generator. You can connect utilities together and make your own plugins that check for problems and transform from one thing to another.
When you are dealing with one type of content (such as markdown), you can use
the main package of that ecosystem instead (so remark
).
When you are dealing with different kinds of content (such as markdown and
HTML), itโs recommended to use unified
itself, and pick and choose the plugins
you need.
This package is ESM only. In Node.js (version 16+), install with npm:
npm install unified
In Deno with esm.sh
:
import {unified} from 'https://esm.sh/unified@11'
In browsers with esm.sh
:
<script type="module">
import {unified} from 'https://esm.sh/unified@11?bundle'
</script>
import rehypeDocument from 'rehype-document'
import rehypeFormat from 'rehype-format'
import rehypeStringify from 'rehype-stringify'
import remarkParse from 'remark-parse'
import remarkRehype from 'remark-rehype'
import {unified} from 'unified'
import {reporter} from 'vfile-reporter'
const file = await unified()
.use(remarkParse)
.use(remarkRehype)
.use(rehypeDocument, {title: '๐๐'})
.use(rehypeFormat)
.use(rehypeStringify)
.process('# Hello world!')
console.error(reporter(file))
console.log(String(file))
Yields:
no issues found
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>๐๐</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
unified
is an interface for processing content with syntax trees.
Syntax trees are a representation of content understandable to programs.
Those programs, called plugins, take these trees and inspect and
modify them.
To get to the syntax tree from text, there is a parser.
To get from that back to text, there is a compiler.
This is the process of a processor.
| ........................ process ........................... |
| .......... parse ... | ... run ... | ... stringify ..........|
+--------+ +----------+
Input ->- | Parser | ->- Syntax Tree ->- | Compiler | ->- Output
+--------+ | +----------+
X
|
+--------------+
| Transformers |
+--------------+
Processors process content.
On its own, unified
(the root processor) doesnโt work.
It needs to be configured with plugins to work.
For example:
const processor = unified()
.use(remarkParse)
.use(remarkRehype)
.use(rehypeDocument, {title: '๐๐'})
.use(rehypeFormat)
.use(rehypeStringify)
That processor can do different things. It can:
parse
)run
)stringify
)process
)Every processor implements another processor. To create a processor, call another processor. The new processor is configured to work the same as its ancestor. But when the descendant processor is configured in the future it does not affect the ancestral processor.
When processors are exposed from a module (for example, unified
itself) they
should not be configured directly, as that would change their behavior for all
module users.
Those processors are frozen and they should be called to create
a new processor before they are used.
When processing a document, metadata is gathered about that document.
vfile
is the file format that stores data, metadata, and messages
about files for unified and plugins.
There are several utilities for working with these files.
The syntax trees used in unified are unist nodes.
A tree represents a whole document and each node is a plain JavaScript
object with a type
field.
The semantics of nodes and the format of syntax trees is defined by other
projects:
There are many utilities for working with trees listed in each aforementioned
project and maintained in the syntax-tree
organization.
These utilities are a level lower than unified itself and are building blocks
that can be used to make plugins.
Around each syntax tree is an ecosystem that focusses on that particular kind of content. At their core, they parse text to a tree and compile that tree back to text. They also provide plugins that work with the syntax tree, without requiring that the end user has knowledge about that tree.
Each aforementioned ecosystem comes with a large set of plugins that you can pick and choose from to do all kinds of things.
remarkjs/awesome-remark
ยท
remark-plugin
topicrehypejs/awesome-rehype
ยท
rehype-plugin
topicretextjs/awesome-retext
ยท
retext-plugin
topicThere are also a few plugins that work in any ecosystem:
unified-diff
โ ignore unrelated messages in GitHub Actions and Travisunified-infer-git-meta
โ infer metadata of a document from Gitunified-message-control
โ enable, disable, and ignore messages from contentProcessors are configured with plugins or with the
data
method.
Most plugins also accept configuration through options.
See each pluginโs readme for more info.
unified can integrate with the file system through
unified-engine
.
CLI apps can be created with unified-args
, Gulp plugins with
unified-engine-gulp
, and language servers with
unified-language-server
.
A streaming interface can be created with unified-stream
.
The API provided by unified
allows multiple files to be processed and
gives access to metadata (such as lint messages):
import rehypeStringify from 'rehype-stringify'
import remarkParse from 'remark-parse'
import remarkPresetLintMarkdownStyleGuide from 'remark-preset-lint-markdown-style-guide'
import remarkRehype from 'remark-rehype'
import remarkRetext from 'remark-retext'
import retextEnglish from 'retext-english'
import retextEquality from 'retext-equality'
import {unified} from 'unified'
import {reporter} from 'vfile-reporter'
const file = await unified()
.use(remarkParse)
.use(remarkPresetLintMarkdownStyleGuide)
.use(remarkRetext, unified().use(retextEnglish).use(retextEquality))
.use(remarkRehype)
.use(rehypeStringify)
.process('*Emphasis* and _stress_, you guys!')
console.error(reporter(file))
console.log(String(file))
Yields:
1:16-1:24 warning Emphasis should use `*` as a marker emphasis-marker remark-lint
1:30-1:34 warning `guys` may be insensitive, use `people`, `persons`, `folks` instead gals-man retext-equality
โ 2 warnings
<p><em>Emphasis</em> and <em>stress</em>, you guys!</p>
Ecosystems can be combined in two modes.
Bridge mode transforms the tree from one format (origin) to another (destination). A different processor runs on the destination tree. Afterwards, the original processor continues with the origin tree.
Mutate mode also transforms the syntax tree from one format to another. But the original processor continues transforming the destination tree.
In the previous example (โProgramming interfaceโ), remark-retext
is used in
bridge mode: the origin syntax tree is kept after retext is done; whereas
remark-rehype
is used in mutate mode: it sets a new syntax tree and discards
the origin tree.
The following plugins lets you combine ecosystems:
remark-retext
โ turn markdown into natural languageremark-rehype
โ turn markdown into HTMLrehype-retext
โ turn HTML into natural languagerehype-remark
โ turn HTML into markdownThis package exports the identifier unified
(the root processor
).
There is no default export.
processor()
Create a new processor.
New unfrozen processor (processor
).
This processor is configured to work the same as its ancestor. When the descendant processor is configured in the future it does not affect the ancestral processor.
This example shows how a new processor can be created (from remark
) and linked
to stdin(4) and stdout(4).
import process from 'node:process'
import concatStream from 'concat-stream'
import {remark} from 'remark'
process.stdin.pipe(
concatStream(function (buf) {
process.stdout.write(String(remark().processSync(buf)))
})
)
processor.compiler
Compiler to use (Compiler
, optional).
processor.data([key[, value]])
Configure the processor with info available to all plugins. Information is stored in an object.
Typically, options can be given to a specific plugin, but sometimes it makes sense to have information shared with several plugins. For example, a list of HTML elements that are self-closing, which is needed during all phases.
๐ Note: setting information cannot occur on frozen processors. Call the processor first to create a new unfrozen processor.
๐ Note: to register custom data in TypeScript, augment the
Data
interface.
processor = processor.data(key, value)
processor = processor.data(dataset)
value = processor.data(key)
dataset = processor.data()
key
(keyof Data
, optional) โ field to getvalue
(Data[key]
) โ value to setvalues
(Data
) โ values to setThe current processor when setting (processor
), the value at
key
when getting (Data[key]
), or the entire dataset when
getting without key (Data
).
This example show how to get and set info:
import {unified} from 'unified'
const processor = unified().data('alpha', 'bravo')
processor.data('alpha') // => 'bravo'
processor.data() // => {alpha: 'bravo'}
processor.data({charlie: 'delta'})
processor.data() // => {charlie: 'delta'}
processor.freeze()
Freeze a processor.
Frozen processors are meant to be extended and not to be configured directly.
When a processor is frozen it cannot be unfrozen. New processors working the same way can be created by calling the processor.
Itโs possible to freeze processors explicitly by calling .freeze()
.
Processors freeze automatically when .parse()
, .run()
, .runSync()
,
.stringify()
, .process()
, or .processSync()
are called.
The current processor (processor
).
This example, index.js
, shows how rehype
prevents extensions to itself:
import rehypeParse from 'rehype-parse'
import rehypeStringify from 'rehype-stringify'
import {unified} from 'unified'
export const rehype = unified().use(rehypeParse).use(rehypeStringify).freeze()
That processor can be used and configured like so:
import {rehype} from 'rehype'
import rehypeFormat from 'rehype-format'
// โฆ
rehype()
.use(rehypeFormat)
// โฆ
A similar looking example is broken as operates on the frozen interface. If this behavior was allowed it would result in unexpected behavior so an error is thrown. This is not valid:
import {rehype} from 'rehype'
import rehypeFormat from 'rehype-format'
// โฆ
rehype
.use(rehypeFormat)
// โฆ
Yields:
~/node_modules/unified/index.js:426
throw new Error(
^
Error: Cannot call `use` on a frozen processor.
Create a new processor first, by calling it: use `processor()` instead of `processor`.
at assertUnfrozen (~/node_modules/unified/index.js:426:11)
at Function.use (~/node_modules/unified/index.js:165:5)
โฆ
processor.parse(file)
Parse text to a syntax tree.
๐ Note:
parse
freezes the processor if not already frozen.
๐ Note:
parse
performs the parse phase, not the run phase or other phases.
file
(Compatible
) โ file to parse; typically
string
or VFile
; any value accepted as x
in new VFile(x)
Syntax tree representing file
(Node
).
This example shows how parse
can be used to create a tree from a file.
import remarkParse from 'remark-parse'
import {unified} from 'unified'
const tree = unified().use(remarkParse).parse('# Hello world!')
console.log(tree)
Yields:
{
type: 'root',
children: [
{type: 'heading', depth: 1, children: [Array], position: [Object]}
],
position: {
start: {line: 1, column: 1, offset: 0},
end: {line: 1, column: 15, offset: 14}
}
}
processor.parser
Parser to use (Parser
, optional).
processor.process(file[, done])
Process the given file as configured on the processor.
๐ Note:
process
freezes the processor if not already frozen.
๐ Note:
process
performs the parse, run, and stringify phases.
processor.process(file, done)
Promise<VFile> = processor.process(file?)
file
(Compatible
, optional) โ file; typically
string
or VFile
; any value accepted as x
in new VFile(x)
done
(ProcessCallback
, optional) โ callbackNothing if done
is given (undefined
).
Otherwise a promise, rejected with a fatal error or resolved with the
processed file (Promise<VFile>
).
The parsed, transformed, and compiled value is available at file.value
(see
note).
๐ Note: unified typically compiles by serializing: most compilers return
string
(orUint8Array
). Some compilers, such as the one configured withrehype-react
, return other values (in this case, a React tree). If youโre using a compiler that doesnโt serialize, expect different result values.To register custom results in TypeScript, add them to
CompileResultMap
.
This example shows how process
can be used to process a file:
import rehypeDocument from 'rehype-document'
import rehypeFormat from 'rehype-format'
import rehypeStringify from 'rehype-stringify'
import remarkParse from 'remark-parse'
import remarkRehype from 'remark-rehype'
import {unified} from 'unified'
const file = await unified()
.use(remarkParse)
.use(remarkRehype)
.use(rehypeDocument, {title: '๐๐'})
.use(rehypeFormat)
.use(rehypeStringify)
.process('# Hello world!')
console.log(String(file))
Yields:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>๐๐</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
processor.processSync(file)
Process the given file as configured on the processor.
An error is thrown if asynchronous transforms are configured.
๐ Note:
processSync
freezes the processor if not already frozen.
๐ Note:
processSync
performs the parse, run, and stringify phases.
file
(Compatible
, optional) โ file; typically
string
or VFile
; any value accepted as x
in new VFile(x)
The processed file (VFile
).
The parsed, transformed, and compiled value is available at file.value
(see
note).
๐ Note: unified typically compiles by serializing: most compilers return
string
(orUint8Array
). Some compilers, such as the one configured withrehype-react
, return other values (in this case, a React tree). If youโre using a compiler that doesnโt serialize, expect different result values.To register custom results in TypeScript, add them to
CompileResultMap
.
This example shows how processSync
can be used to process a file, if all
transformers are synchronous.
import rehypeDocument from 'rehype-document'
import rehypeFormat from 'rehype-format'
import rehypeStringify from 'rehype-stringify'
import remarkParse from 'remark-parse'
import remarkRehype from 'remark-rehype'
import {unified} from 'unified'
const processor = unified()
.use(remarkParse)
.use(remarkRehype)
.use(rehypeDocument, {title: '๐๐'})
.use(rehypeFormat)
.use(rehypeStringify)
console.log(String(processor.processSync('# Hello world!')))
Yields:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>๐๐</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
processor.run(tree[, file][, done])
Run transformers on a syntax tree.
๐ Note:
run
freezes the processor if not already frozen.
๐ Note:
run
performs the run phase, not other phases.
processor.run(tree, done)
processor.run(tree, file, done)
Promise<Node> = processor.run(tree, file?)
tree
(Node
) โ tree to transform and inspectfile
(Compatible
, optional) โ file associated
with node
; any value accepted as x
in new VFile(x)
done
(RunCallback
, optional) โ callbackNothing if done
is given (undefined
).
Otherwise, a promise rejected with a fatal error or resolved with the
transformed tree (Promise<Node>
).
This example shows how run
can be used to transform a tree:
import remarkReferenceLinks from 'remark-reference-links'
import {unified} from 'unified'
import {u} from 'unist-builder'
const tree = u('root', [
u('paragraph', [
u('link', {href: 'https://example.com'}, [u('text', 'Example Domain')])
])
])
const changedTree = await unified().use(remarkReferenceLinks).run(tree)
console.log(changedTree)
Yields:
{
type: 'root',
children: [
{type: 'paragraph', children: [Array]},
{type: 'definition', identifier: '1', title: '', url: undefined}
]
}
processor.runSync(tree[, file])
Run transformers on a syntax tree.
An error is thrown if asynchronous transforms are configured.
๐ Note:
runSync
freezes the processor if not already frozen.
๐ Note:
runSync
performs the run phase, not other phases.
tree
(Node
) โ tree to transform and inspectfile
(Compatible
, optional) โ file associated
with node
; any value accepted as x
in new VFile(x)
Transformed tree (Node
).
processor.stringify(tree[, file])
Compile a syntax tree.
๐ Note:
stringify
freezes the processor if not already frozen.
๐ Note:
stringify
performs the stringify phase, not the run phase or other phases.
tree
(Node
) โ tree to compilefile
(Compatible
, optional) โ file associated
with node
; any value accepted as x
in new VFile(x)
Textual representation of the tree (Uint8Array
or string
, see note).
๐ Note: unified typically compiles by serializing: most compilers return
string
(orUint8Array
). Some compilers, such as the one configured withrehype-react
, return other values (in this case, a React tree). If youโre using a compiler that doesnโt serialize, expect different result values.To register custom results in TypeScript, add them to
CompileResultMap
.
This example shows how stringify
can be used to serialize a syntax tree:
import {h} from 'hastscript'
import rehypeStringify from 'rehype-stringify'
import {unified} from 'unified'
const tree = h('h1', 'Hello world!')
const document = unified().use(rehypeStringify).stringify(tree)
console.log(document)
Yields:
<h1>Hello world!</h1>
processor.use(plugin[, options])
Configure the processor to use a plugin, a list of usable values, or a preset.
If the processor is already using a plugin, the previous plugin configuration is changed based on the options that are passed in. In other words, the plugin is not added a second time.
๐ Note:
use
cannot be called on frozen processors. Call the processor first to create a new unfrozen processor.
processor.use(preset?)
processor.use(list)
processor.use(plugin[, ...parameters])
preset
(Preset
) โ plugins and settingslist
(PluggableList
) โ list of usable thingsplugin
(Plugin
) โ pluginparameters
(Array<unknown>
) โ configuration for plugin
, typically a
single options objectCurrent processor (processor
).
There are many ways to pass plugins to .use()
.
This example gives an overview:
import {unified} from 'unified'
unified()
// Plugin with options:
.use(pluginA, {x: true, y: true})
// Passing the same plugin again merges configuration (to `{x: true, y: false, z: true}`):
.use(pluginA, {y: false, z: true})
// Plugins:
.use([pluginB, pluginC])
// Two plugins, the second with options:
.use([pluginD, [pluginE, {}]])
// Preset with plugins and settings:
.use({plugins: [pluginF, [pluginG, {}]], settings: {position: false}})
// Settings only:
.use({settings: {position: false}})
CompileResultMap
Interface of known results from compilers (TypeScript type).
Normally, compilers result in text (Value
of vfile
).
When you compile to something else, such as a React node (as in,
rehype-react
), you can augment this interface to include that type.
import type {ReactNode} from 'somewhere'
declare module 'unified' {
interface CompileResultMap {
// Register a new result (value is used, key should match it).
ReactNode: ReactNode
}
}
export {} // You may not need this, but it makes sure the file is a module.
Use CompileResults
to access the values.
interface CompileResultMap {
// Note: if `Value` from `VFile` is changed, this should too.
Uint8Array: Uint8Array
string: string
}
CompileResults
Acceptable results from compilers (TypeScript type).
To register custom results, add them to
CompileResultMap
.
type CompileResults = CompileResultMap[keyof CompileResultMap]
Compiler
A compiler handles the compiling of a syntax tree to something else (in most cases, text) (TypeScript type).
It is used in the stringify phase and called with a Node
and VFile
representation of the document to compile.
It should return the textual representation of the given tree (typically
string
).
๐ Note: unified typically compiles by serializing: most compilers return
string
(orUint8Array
). Some compilers, such as the one configured withrehype-react
, return other values (in this case, a React tree). If youโre using a compiler that doesnโt serialize, expect different result values.To register custom results in TypeScript, add them to
CompileResultMap
.
type Compiler<
Tree extends Node = Node,
Result extends CompileResults = CompileResults
> = (tree: Tree, file: VFile) => Result
Data
Interface of known data that can be supported by all plugins (TypeScript type).
Typically, options can be given to a specific plugin, but sometimes it makes sense to have information shared with several plugins. For example, a list of HTML elements that are self-closing, which is needed during all phases.
To type this, do something like:
declare module 'unified' {
interface Data {
htmlVoidElements?: Array<string> | undefined
}
}
export {} // You may not need this, but it makes sure the file is a module.
interface Data {
settings?: Settings | undefined
}
See Settings
for more info.
Parser
A parser handles the parsing of text to a syntax tree (TypeScript type).
It is used in the parse phase and is called with a string
and
VFile
of the document to parse.
It must return the syntax tree representation of the given file
(Node
).
type Parser<Tree extends Node = Node> = (document: string, file: VFile) => Tree
Pluggable
Union of the different ways to add plugins and settings (TypeScript type).
type Pluggable =
| Plugin<Array<any>, any, any>
| PluginTuple<Array<any>, any, any>
| Preset
See Plugin
, PluginTuple
,
and Preset
for more info.
PluggableList
List of plugins and presets (TypeScript type).
type PluggableList = Array<Pluggable>
See Pluggable
for more info.
Plugin
Single plugin (TypeScript type).
Plugins configure the processors they are applied on in the following ways:
In practice, they are functions that can receive options and configure the
processor (this
).
๐ Note: plugins are called when the processor is frozen, not when they are applied.
type Plugin<
PluginParameters extends unknown[] = [],
Input extends Node | string | undefined = Node,
Output = Input
> = (
this: Processor,
...parameters: PluginParameters
) => Input extends string // Parser.
? Output extends Node | undefined
? undefined | void
: never
: Output extends CompileResults // Compiler.
? Input extends Node | undefined
? undefined | void
: never
: // Inspect/transform.
| Transformer<
Input extends Node ? Input : Node,
Output extends Node ? Output : Node
>
| undefined
| void
See Transformer
for more info.
move.js
:
/**
* @typedef Options
* Configuration (required).
* @property {string} extname
* File extension to use (must start with `.`).
*/
/** @type {import('unified').Plugin<[Options]>} */
export function move(options) {
if (!options || !options.extname) {
throw new Error('Missing `options.extname`')
}
return function (_, file) {
if (file.extname && file.extname !== options.extname) {
file.extname = options.extname
}
}
}
example.md
:
# Hello, world!
example.js
:
import rehypeStringify from 'rehype-stringify'
import remarkParse from 'remark-parse'
import remarkRehype from 'remark-rehype'
import {read, write} from 'to-vfile'
import {unified} from 'unified'
import {reporter} from 'vfile-reporter'
import {move} from './move.js'
const file = await unified()
.use(remarkParse)
.use(remarkRehype)
.use(move, {extname: '.html'})
.use(rehypeStringify)
.process(await read('example.md'))
console.error(reporter(file))
await write(file) // Written to `example.html`.
Yields:
example.md: no issues found
โฆand in example.html
:
<h1>Hello, world!</h1>
PluginTuple
Tuple of a plugin and its configuration (TypeScript type).
The first item is a plugin, the rest are its parameters.
type PluginTuple<
TupleParameters extends unknown[] = [],
Input extends Node | string | undefined = undefined,
Output = undefined
> = [
plugin: Plugin<TupleParameters, Input, Output>,
...parameters: TupleParameters
]
See Plugin
for more info.
Preset
Sharable configuration (TypeScript type).
They can contain plugins and settings.
plugins
(PluggableList
, optional)
โ list of plugins and presetssettings
(Data
, optional)
โ shared settings for parsers and compilerspreset.js
:
import remarkCommentConfig from 'remark-comment-config'
import remarkLicense from 'remark-license'
import remarkPresetLintConsistent from 'remark-preset-lint-consistent'
import remarkPresetLintRecommended from 'remark-preset-lint-recommended'
import remarkToc from 'remark-toc'
/** @type {import('unified').Preset} */
const preset = {
plugins: [
remarkPresetLintRecommended,
remarkPresetLintConsistent,
remarkCommentConfig,
[remarkToc, {maxDepth: 3, tight: true}],
remarkLicense
]
settings: {bullet: '*', emphasis: '*', fences: true},
}
export default preset
example.md
:
# Hello, world!
_Emphasis_ and **importance**.
## Table of contents
## API
## License
example.js
:
import {remark} from 'remark'
import {read, write} from 'to-vfile'
import {reporter} from 'vfile-reporter'
import preset from './preset.js'
const file = await remark()
.use(preset)
.process(await read('example.md'))
console.error(reporter(file))
await write(file)
Yields:
example.md: no issues found
example.md
now contains:
# Hello, world!
*Emphasis* and **importance**.
## Table of contents
* [API](#api)
* [License](#license)
## API
## License
[MIT](license) ยฉ [Titus Wormer](https://wooorm.com)
ProcessCallback
Callback called when the process is done (TypeScript type).
Called with either an error or a result.
error
(Error
, optional)
โ fatal errorfile
(VFile
, optional)
โ processed fileNothing (undefined
).
This example shows how process
can be used to process a file with a callback.
import remarkGithub from 'remark-github'
import remarkParse from 'remark-parse'
import remarkStringify from 'remark-stringify'
import {unified} from 'unified'
import {reporter} from 'vfile-reporter'
unified()
.use(remarkParse)
.use(remarkGithub)
.use(remarkStringify)
.process('@unifiedjs', function (error, file) {
if (error) throw error
if (file) {
console.error(reporter(file))
console.log(String(file))
}
})
Yields:
no issues found
[**@unifiedjs**](https://github.com/unifiedjs)
Processor
Type of a processor
(TypeScript type).
RunCallback
Callback called when transformers are done (TypeScript type).
Called with either an error or results.
error
(Error
, optional)
โ fatal errortree
(Node
, optional)
โ transformed treefile
(VFile
, optional)
โ fileNothing (undefined
).
Settings
Interface of known extra options, that can be supported by parser and compilers.
This exists so that users can use packages such as remark
, which configure
both parsers and compilers (in this case remark-parse
and
remark-stringify
), and still provide options for them.
When you make parsers or compilers, that could be packaged up together, you
should support this.data('settings')
as input and merge it with explicitly
passed options
.
Then, to type it, using remark-stringify
as an example, do something like:
declare module 'unified' {
interface Settings {
bullet: '*' | '+' | '-'
// โฆ
}
}
export {} // You may not need this, but it makes sure the file is a module.
interface Settings {}
TransformCallback
Callback passed to transforms (TypeScript type).
If the signature of a transformer
accepts a third argument, the transformer
may perform asynchronous operations, and must call it.
error
(Error
, optional)
โ fatal error to stop the processtree
(Node
, optional)
โ new, changed, treefile
(VFile
, optional)
โ new, changed, fileNothing (undefined
).
Transformer
Transformers handle syntax trees and files (TypeScript type).
They are functions that are called each time a syntax tree and file are
passed through the run phase.
When an error occurs in them (either because itโs thrown, returned,
rejected, or passed to next
), the process stops.
The run phase is handled by trough
, see its documentation for
the exact semantics of these functions.
๐ Note: you should likely ignore
next
: donโt accept it. it supports callback-style async work. But promises are likely easier to reason about.
type Transformer<
Input extends Node = Node,
Output extends Node = Input
> = (
tree: Input,
file: VFile,
next: TransformCallback<Output>
) =>
| Promise<Output | undefined>
| Output
| Error
| undefined
This package is fully typed with TypeScript.
It exports the additional types
CompileResultMap
,
CompileResults
,
Compiler
,
Data
,
Parser
,
Pluggable
,
PluggableList
,
Plugin
,
PluginTuple
,
Preset
,
ProcessCallback
,
Processor
,
RunCallback
,
Settings
,
TransformCallback
,
and Transformer
For TypeScript to work, it is particularly important to type your plugins
correctly.
We strongly recommend using the Plugin
type with its generics and to use the
node types for the syntax trees provided by our packages (as in,
@types/hast
, @types/mdast
,
@types/nlcst
).
/**
* @typedef {import('hast').Root} HastRoot
* @typedef {import('mdast').Root} MdastRoot
*/
/**
* @typedef Options
* Configuration (optional).
* @property {boolean | null | undefined} [someField]
* Some option (optional).
*/
// To type options:
/** @type {import('unified').Plugin<[(Options | null | undefined)?]>} */
export function myPluginAcceptingOptions(options) {
const settings = options || {}
// `settings` is now `Options`.
}
// To type a plugin that works on a certain tree, without options:
/** @type {import('unified').Plugin<[], MdastRoot>} */
export function myRemarkPlugin() {
return function (tree, file) {
// `tree` is `MdastRoot`.
}
}
// To type a plugin that transforms one tree into another:
/** @type {import('unified').Plugin<[], MdastRoot, HastRoot>} */
export function remarkRehype() {
return function (tree) {
// `tree` is `MdastRoot`.
// Result must be `HastRoot`.
}
}
// To type a plugin that defines a parser:
/** @type {import('unified').Plugin<[], string, MdastRoot>} */
export function remarkParse(options) {}
// To type a plugin that defines a compiler:
/** @type {import('unified').Plugin<[], HastRoot, string>} */
export function rehypeStringify(options) {}
Projects maintained by the unified collective are compatible with maintained versions of Node.js.
When we cut a new major release, we drop support for unmaintained versions of
Node.
This means we try to keep the current release line, unified@^11
, compatible
with Node.js 16.
See contributing.md
in unifiedjs/.github
for ways
to get started.
See support.md
for ways to get help.
This project has a code of conduct. By interacting with this repository, organization, or community you agree to abide by its terms.
For info on how to submit a security report, see our security policy.
Support this effort and give back by sponsoring on OpenCollective!
Vercel |
Motif |
HashiCorp |
American Express |
GitBook | |||
Gatsby |
Netlify |
Coinbase |
ThemeIsle |
Expo |
Boost Note |
Markdown Space |
Holloway |
You? |
Preliminary work for unified was done in 2014 for
retext and inspired by ware
.
Further incubation happened in remark.
The project was finally externalised in 2015 and published as unified
.
The project was authored by @wooorm.
Although unified
since moved its plugin architecture to trough
,
thanks to @calvinfo,
@ianstormtaylor, and others for their
work on ware
, as it was a huge initial inspiration.
MIT ยฉ Titus Wormer
FAQs
parse, inspect, transform, and serialize content through syntax trees
The npm package unified receives a total of 8,945,894 weekly downloads. As such, unified popularity was classified as popular.
We found that unified demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago.ย It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.