remark-lint rule to warn when fenced code blocks have an inconsistently-cased language flag

![Black Lives Matter!][x-badge-blm-image] ![Last commit timestamp][x-badge-lastcommit-image] ![Codecov][x-badge-codecov-image] [![Source license][x-badge-license-image]][x-badge-license-link] [![Uses Semantic Release!][x-badge-semanticrelease-image]][x-badge-semanticrelease-link] ![NPM version][x-badge-npm-image] [![Monthly Downloads][x-badge-downloads-image]][x-badge-downloads-link]

remark-lint-fenced-code-flag-case

This is a remark-lint rule to warn when fenced code blocks have inconsistent or improperly cased language flags. Also comes with full unicode support.

This check is useful when using [a tool like prettier that formats fenced code blocks][2], since such tools do not consistently recognize uppercase or mixed-case code flags. That is: code fenced with the flag typescript or markdown will be formatted while code fenced with the flag TypeScript or MARKDOWN may be silently ignored, even as syntax highlighting still works, which results in a false sense of correctness.

Install

Due to the nature of the unified ecosystem, this package is ESM only and cannot be require'd.

To install:

npm install --save-dev remark-lint-fenced-code-flag-case

Usage

For maximum flexibility, there are several ways this plugin can be invoked.

Via API

import { read } from 'to-vfile';
import { reporter } from 'vfile-reporter';
import { remark } from 'remark';
import remarkLint from 'remark-lint';
import lintFencedCodeFlagCase from 'remark-lint-fenced-code-flag-case';

const file = await remark()
  .use(remarkLint)
  .use(lintFencedCodeFlagCase)
  .process(await read('example.md'));

console.log(reporter(file));

Via remark-cli

remark --use remark-lint --use lint-fenced-code-flag-case README.md

Via unified configuration

In package.json:

  /* … */
  "remarkConfig": {
    "plugins": [
      "remark-lint-fenced-code-flag-case"
      /* … */
    ]
  },
  /* … */

In .remarkrc.js:

module.exports = {
  plugins: [
    // …
    'lint-fenced-code-flag-case'
  ]
};

In .remarkrc.mjs:

import lintFencedCodeFlagCase from 'remark-lint-fenced-code-flag-case';

export default {
  plugins: [
    // …
    lintFencedCodeFlagCase
  ]
};

API

Detailed interface information can be found under docs/.

Options

This rule supports standard configuration that all remark lint rules accept (such as false to turn it off or [1, options] to configure it).

Additionally, this plugin recognizes the following options:

`case`

Valid values: "lower" | "upper" | "capitalize"\ Default: "lower"

All code fence flags must be of the specified case. Code fences without flags are ignored.

Examples

`ok-missing.md`

In

# Document

```
Text.
```

Out

No messages.

`ok-lower.md`

In

# Document

```js
const str = 'string';
```

```javascript
const str = 'string';
```

Out

No messages.

`not-ok-mixed.md`

In

# Document

```Js
const str = 'string';
```

```JavaScript
const str = 'string';
```

Out

3:1-5:4: Code fence flag "Js" should be "js"
7:1-10:5: Code fence flag "JavaScript" should be "javascript"

`not-ok-upper.md`

In

# Document

```JS
const str = 'string';
```

```JAVASCRIPT
const str = 'string';
```

Out

3:1-5:4: Code fence flag "JS" should be "js"
7:1-10:5: Code fence flag "JAVASCRIPT" should be "javascript"

[remark-lint-fenced-code-flag][4] — warn when fenced code blocks occur without language flag.
[remark-lint-fenced-code-marker][5] — warn when fenced code markers violate the given style.

Appendix

Further documentation can be found under docs/.

Published Package Details

This is an [ESM-only package][x-pkg-esm-wine] built by Babel for use in Node.js versions that are not end-of-life. For TypeScript users, this package supports both "Node10" and "Node16" module resolution strategies.

<summary>Expand details</summary> That means ESM source will load this package via import { ... } from ... or await import(...) and CJS source will load this package via dynamic import(). This has several benefits, the foremost being: less code shipped/smaller package size, avoiding [dual package hazard][x-pkg-dual-package-hazard] entirely, distributables are not packed/bundled/uglified, and a drastically less complex build process. The glaring downside, which may or may not be relevant, is that CJS consumers cannot require() this package and can only use import() in an asynchronous context. This means, in effect, CJS consumers may not be able to use this package at all. Each entry point (i.e. ENTRY) in package.json's exports[ENTRY] object includes one or more [export conditions][x-pkg-exports-conditions]. These entries may or may not include: an [exports[ENTRY].types][x-pkg-exports-types-key] condition pointing to a type declaration file for TypeScript and IDEs, a [exports[ENTRY].module][x-pkg-exports-module-key] condition pointing to (usually ESM) source for Webpack/Rollup, a exports[ENTRY].node and/or exports[ENTRY].default condition pointing to (usually CJS2) source for Node.js require/import and for browsers and other environments, and [other conditions][x-pkg-exports-conditions] not enumerated here. Check the package.json file to see which export conditions are supported. Note that, regardless of the [{ "type": "..." }][x-pkg-type] specified in package.json, any JavaScript files written in ESM syntax (including distributables) will always have the .mjs extension. Note also that package.json may include the [sideEffects][x-pkg-side-effects-key] key, which is almost always false for optimal tree shaking where appropriate.

License

See LICENSE.

Contributing and Support

[New issues][x-repo-choose-new-issue] and pull requests are always welcome and greatly appreciated! 🤩 Just as well, you can star 🌟 this project to let me know you found it useful! ✊🏿 Or buy me a beer, I'd appreciate it. Thank you!

See CONTRIBUTING.md and SUPPORT.md for more information.