built for speed.^*
a low-level markdown compiler that allows frequent parsing of large chunks of markdown without caching or blocking for long periods of time.^**
light-weight while implementing all markdown features from the supported flavors & specifications.^***
available as a command line interface (CLI) and running in client- or server-side JavaScript projects.

^* Still working on metrics for comparative analysis and definition.
^** As few dependencies as possible.
^*** Strict compliance could result in slower processing when running comparative benchmarking.

Installation
Usage
marked()
Options
Extend
CLI
Philosophy
Benchmarks
Contributing
License

Installation

CLI: npm install -g marked

In-browser: npm install marked --save

Usage

CLI

$ marked -o hello.html
hello world
^D
$ cat hello.html
<p>hello world</p>

Browser

<!doctype html>
<html>
<head>
  <meta charset="utf-8"/>
  <title>Marked in the browser</title>
  <script src="/path/to/marked.min.js"></script>
</head>
<body>
  <div id="content"></div>
  <script>
    document.getElementById('content').innerHTML =
      marked('# Marked in browser\n\nRendered by **marked**.');
  </script>
</body>
</html>

Marked offers advanced configurations and extensibility as well.

Access to lexer and parser

You also have direct access to the lexer and parser if you so desire.

var tokens = marked.lexer(text, options);
console.log(marked.parser(tokens));

var lexer = new marked.Lexer(options);
var tokens = lexer.lex(text);
console.log(tokens);
console.log(lexer.rules);

Benchmarks

node v8.9.4

$ npm run bench
marked completed in 3408ms.
marked (gfm) completed in 3465ms.
marked (pedantic) completed in 3032ms.
showdown (reuse converter) completed in 21444ms.
showdown (new converter) completed in 23058ms.
markdown-it completed in 3364ms.
markdown.js completed in 12090ms.

Pro level

You also have direct access to the lexer and parser if you so desire.

var tokens = marked.lexer(text, options);
console.log(marked.parser(tokens));

var lexer = new marked.Lexer(options);
var tokens = lexer.lex(text);
console.log(tokens);
console.log(lexer.rules);

$ node
> require('marked').lexer('> i am using marked.')
[ { type: 'blockquote_start' },
  { type: 'paragraph',
    text: 'i am using marked.' },
  { type: 'blockquote_end' },
  links: {} ]

Contributing

If the code in a pull request can have a test written for it, it should have it. (If the test already exists, please reference the test which should pass.)
Do not merge your own. Mainly for collaborators and owners, please do not review and merge your own PRs.

Tests

The marked test suite is set up slightly strangely: test/new is for all tests that are not part of the original markdown.pl test suite (this is where your test should go if you make one). test/original is only for the original markdown.pl tests.

In other words, if you have a test to add, add it to test/new/. If your test uses a certain feature, for example, maybe it assumes GFM is not enabled, you can add front-matter to the top of your .md file

---
gfm: false
---

To run the tests:

npm run test

Contribution License Agreement

If you contribute code to this project, you are implicitly allowing your code to be distributed under the MIT license. You are also implicitly verifying that all code is your original work. </legalese>

Releasing

Master is always shippable: We try to merge PRs in such a way that master is the only branch to really be concerned about and master can always be released. This allows smoother flow between new fetures, bug fixes, and so on. (Almost a continuous deployment setup, without automation.)

Version naming: relatively standard [major].[minor].[patch] where major releases represent known breaking changes to the previous release, minor represent additions of new funcitonality without breaking changes, and patch releases represent changes meant to fix previously released functionality with no new functionality. Note: When the major is a zero, it means the library is still in a beta state wherein the major does not get updated; therefore, minor releases may introduce breaking changes, and patch releases may contain new features.

Release process:

Check out library
Make sure you are on the master branch
Create release branch from master
$ npm run build (builds minified version and whatnot)
$ npm version [major|minor|patch] (updates package.json)
$ npm publish (publishes package to NPM)
Submit PR
Merge PR (only time where submitter should be "allowed" to merge his or her own)
Navigate to the "Releases" tab on the project main page -> "Draft new release"
Add version number matching the one in the package.json file after publishing the release
Make sure master is the branch from which the release will be made
Add notes regarding what users should expect from the release
Click "Publish release"

License

See LICENSE for more details.