v2.0.0-alpha.0

• 51e48c6 Docs: Revamp documentation for v2 (#149) (Brandon Mills)
• b221391 Docs: Dogfood plugin by linting readme (#145) (Brandon Mills)
• 7423610 Docs: Explain use of --ext option in ESLint v7 (#146) (Brandon Mills)
• 0d4dbe8 Breaking: Implement new processor API (fixes #138) (#144) (Brandon Mills)
• 7eeafb8 Chore: Update ESLint config and plugins (#143) (Brandon Mills)
• f483343 Breaking: Require ESLint v6 (#142) (Brandon Mills)
• 9aa1fdc Chore: Use ES2018 object spread syntax (#141) (Brandon Mills)
• f584cc6 Build: Remove Travis (#140) (Brandon Mills)
• 35f9a11 Breaking: Drop support for Node.js v6 (refs #138) (#137) (Brandon Mills)
• 6f02ef5 Chore: Add npm version and build status badges (#139) (Brandon Mills)

Migrating from eslint-plugin-markdown v1

eslint-plugin-markdown v1 used an older version of ESLint's processor API.
The Markdown processor automatically ran on .md, .mkdn, .mdown, and .markdown files, and it only extracted fenced code blocks marked with js, javascript, jsx, or node syntax.
Configuration specifically for fenced code blocks went inside an overrides entry with a files pattern matching the containing Markdown document's filename that applied to all fenced code blocks inside the file.

// .eslintrc.js for eslint-plugin-markdown v1
module.exports = {
    plugins: ["markdown"],
    overrides: [
        {
            files: ["**/*.md"],
            // In v1, configuration for fenced code blocks went inside an
            // `overrides` entry with a .md pattern, for example:
            parserOptions: {
                ecmaFeatures: {
                    impliedStrict: true
                }
            },
            rules: {
                "no-console": "off"
            }
        }
    ]
};

RFC3 designed a new processor API to remove these limitations, and the new API was implemented as part of ESLint v6.
eslint-plugin-markdown v2 uses this new API.

$ npm install --save-dev eslint@latest eslint-plugin-markdown@next

All of the Markdown file extensions that were previously hard-coded are now fully configurable in .eslintrc.js.
Use the new processor option to apply the markdown/markdown processor on any Markdown documents matching a files pattern.
Each fenced code block inside a Markdown document has a virtual filename appended to the Markdown file's path.
The virtual filename's extension will match the fenced code block's syntax tag, so for example, ```js code blocks in README.md would match README.md/*.js.

// eslintrc.js for eslint-plugin-markdown v2
module.exports = {
    plugins: ["markdown"],
    overrides: [
        {
            // In v2, explicitly apply eslint-plugin-markdown's `markdown`
            // processor on any Markdown files you want to lint.
            files: ["**/*.md"],
            processor: "markdown/markdown"
        },
        {
            // In v2, configuration for fenced code blocks is separate from the
            // containing Markdown file. Each code block has a virtual filename
            // appended to the Markdown file's path.
            files: ["**/*.md/*.js"],
            // Configuration for fenced code blocks goes with the override for
            // the code block's virtual filename, for example:
            parserOptions: {
                ecmaFeatures: {
                    impliedStrict: true
                }
            },
            rules: {
                "no-console": "off"
            }
        }
    ]
};

If you need to precisely mimic the behavior of v1 with the hard-coded Markdown extensions and fenced code block syntaxes, you can use those as glob patterns in overrides[].files:

// eslintrc.js for v2 mimicking v1 behavior
module.exports = {
    plugins: ["markdown"],
    overrides: [
        {
            files: ["**/*.{md,mkdn,mdown,markdown}"],
            processor: "markdown/markdown"
        },
        {
            files: ["**/*.{md,mkdn,mdown,markdown}/*.{js,javascript,jsx,node}"]
            // ...
        }
    ]
};