Package Exports
- remark-tight-comments
- remark-tight-comments/package
- remark-tight-comments/package.json
Readme
remark plugin to selectively remove newlines around comments
remark-tight-comments
This is a unified (remark) plugin that allows you to selectively remove unnecessary newlines around Markdown comments.
This plugin is useful for preserving the structure of auto-generated content, e.g. all-contributors, doctoc, etc. You might also be interested in remark-ignore, which lets you instruct remark not to transform parts of your Markdown documents. For a live example of these two plugins in action, check the source of this very README.md file. ✨
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-tight-commentsUsage
For maximum flexibility, there are several ways this plugin can be invoked.
Via API
import { read } from 'to-vfile';
import { remark } from 'remark';
import remarkTightComments from 'remark-tight-comments';
const file = await remark()
.use(remarkTightComments)
.process(await read('example.md'));
console.log(String(file));Via remark-cli
remark -o --use tight-comments README.mdVia unified configuration
In package.json:
/* … */
"remarkConfig": {
"plugins": [
"remark-tight-comments"
/* … */
]
},
/* … */In .remarkrc.js:
module.exports = {
plugins: [
// …
'tight-comments'
]
};In .remarkrc.mjs:
import remarkTightComments from 'remark-tight-comments';
export default {
plugins: [
// …
remarkTightComments
]
};API
Detailed interface information can be found under docs/.
Examples
See mdast-util-tight-comments for example outputs.
Related
- remark-ignore — use comments to exclude one or more nodes from transformation.
- mdast-util-tight-comments — selectively remove newlines around comment nodes during serialization.
Appendix
Further documentation can be found under docs/.
Published Package Details
This is an ESM-only package 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.
Expand details
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 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. These entries may or may not include: an
exports[ENTRY].types condition pointing to a type
declaration file for TypeScript and IDEs, a
exports[ENTRY].module 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 not enumerated here. Check the
package.json file to see which export conditions are
supported.
Note that, regardless of the { "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 key, which is almost always false for
optimal tree shaking where appropriate.
License
See LICENSE.
Contributing and Support
New issues 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.
Contributors
See the table of contributors.