-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update: Upgrade remark-parse to v7 (fixes #77, fixes #78) #175
Conversation
`remark-parse@7.0.0` includes remarkjs/remark#423, which fixes handling of leading and trailing newlines in fenced code blocks. Tagging this as `Update` so it'll be semver-minor. Are we comfortable with a parser major version bump in a semver-minor release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for the review @nzakas. What are your thoughts on those three follow-up questions in the description? I at least want v7 to fix these bugs, but I could use some input on v8 or v9. |
Ah sorry, totally breezed over those. My vote would be to just do the minimum to fix the issues we were having right now (stop the bleeding). We can always do further upgrades later but I’d rather get a safe fix out first. |
All Since - const unified = require("unified");
- const remarkParse = require("remark-parse");
+ const fromMarkdown = require("mdast-util-from-markdown");
- const markdown = unified().use(remarkParse);
-
/** function preprocess(text, filename) {
- const ast = markdown.parse(text);
+ const ast = fromMarkdown(text);
const blocks = []; |
Thanks for the tip @remcohaszing. It'd be nice to reduce the size of the dependency tree, so I gave that a shot, but it has the same change to indents that I pointed out in #171 (comment). That makes using |
The previous parser, `remark-parse` v7, included a transitive dependency on an npm package with a security vulnerability. Newer versions of `remark-parse` are wrappers around a new underlying parser, `mdast-util-from-markdown`, so we can use that directly. The previous parser also failed to preserve `\r\n` line endings, replacing them all with `\n`. The new parser correctly preserves `\r\n` line endings, finally providing a fix for the failing test case I cherry-picked in the previous commit. The improved behavior also uncovered an incorrect line ending test assertion that this commit corrects. While this change is in theory fully compatible, containing just bug fixes, I'm tagging it `Update:` in case there are compatibility changes in the new parser. This is consistent with #175, which upgraded `remark-parse` v5 to v7 in a semver-minor `Update:` change.
* Docs: Fix typo in comment * Docs: Add RangeMap JSDoc property descriptions * Fix: Use internally-calculated code block trim lengths Future versions of the Markdown processor don't include per-line indent information. Thankfully, we're already calculating it in `getBlockRangeMap()` because we need it to correctly map fix ranges for lines that are under-indented to the left of their opening code fence. This includes the indent in the `RangeMap` for each line and uses that in `adjustBlock()` instead. This uncovered an incorrect assertion in one of the tests, which combined an indented code block, a message on a line with mixed spaces and tabs indentation, and an under-indented final line. The message column was incorrectly asserted as being in the whitespace indentation before the line. * Chore: Test multline autofix with CRLF Originally discovered in #120 and cherry-picked from #125. * Update: Replace Markdown parser (fixes #125, fixes #186) The previous parser, `remark-parse` v7, included a transitive dependency on an npm package with a security vulnerability. Newer versions of `remark-parse` are wrappers around a new underlying parser, `mdast-util-from-markdown`, so we can use that directly. The previous parser also failed to preserve `\r\n` line endings, replacing them all with `\n`. The new parser correctly preserves `\r\n` line endings, finally providing a fix for the failing test case I cherry-picked in the previous commit. The improved behavior also uncovered an incorrect line ending test assertion that this commit corrects. While this change is in theory fully compatible, containing just bug fixes, I'm tagging it `Update:` in case there are compatibility changes in the new parser. This is consistent with #175, which upgraded `remark-parse` v5 to v7 in a semver-minor `Update:` change.
remark-parse@7.0.0
includes remarkjs/remark#423, which fixes handling of leading and trailing newlines in fenced code blocks.For reviewers:
remark-parse
v6, v7, and v8 were semver-major fixes. v9 was a full rewrite. Are we comfortable with a parser major version bump in a semver-minor release? This is currently tagged asUpdate:
so it's semver-minor rather than semver-patch.eslint-plugin-markdown
issues that would be fixed by v8 or v9.eslint-plugin-markdown
, should we stop at v8 or go all the way to the re-written parser in v9? If the latter, I'll close this in favor of Chore: upgrade remark-parse to 9.0.0 #171.Changelogs:
remark-parse@6.0.0
remark-parse@7.0.0
remark-parse@8.0.0
remark-parse@9.9.0