Skip to content
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.

Sign up for GitHub

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

Chore: upgrade remark-parse to 9.0.0 #171

Closed
wants to merge 2 commits into from
Closed

Chore: upgrade remark-parse to 9.0.0 #171

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c69ad9f
Chore: upgrade remark-parse to 9.0.0
aduh95 Feb 2, 2021
cdc9737
fixup! Chore: upgrade remark-parse to 9.0.0
aduh95 Feb 4, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions lib/processor.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ function preprocess(text) {
});

return blocks.map((block, index) => ({
filename: `${index}.${block.lang.trim().split(" ")[0]}`,
filename: `${index}.${block.lang}`,
text: [
...block.comments,
block.value,
Expand Down Expand Up @@ -286,7 +286,7 @@ function adjustBlock(block) {

const out = {
line: lineInCode + blockStart,
column: message.column + block.position.indent[lineInCode - 1] - 1
column: message.column + block.baseIndentText.length
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is valid in the case of "negative" indents, i.e. lines of code in a code block that are less indented than the opening fence. The parser previously gave us those on a per-line basis so we could make the correct adjustment. That shows up in the change to the "should translate indented column numbers" test, where one of the messages' columns (4) is now greater than the line length (2).

};

if (Number.isInteger(message.endLine)) {
Expand Down
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@
"nyc": "^14.1.1"
},
"dependencies": {
"remark-parse": "^5.0.0",
"remark-parse": "^9.0.0",
"unified": "^6.1.2"
},
"peerDependencies": {
Expand Down
8 changes: 4 additions & 4 deletions tests/lib/processor.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,7 @@ describe("processor", () => {

assert.strictEqual(blocks.length, 1);
assert.strictEqual(blocks[0].filename, "0.js");
assert.strictEqual(blocks[0].text, "\n\n \n \n");
assert.strictEqual(blocks[0].text, "\n\n\n \n \n");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! This reminded me of both #77 and #78. After some digging, it turns out [email protected] includes remarkjs/remark#423, which fixes both of those issues. I opened #175 with a few additional tests specifically demonstrating those fixes.

});

it("should ignore code fences with unspecified info string", () => {
Expand Down Expand Up @@ -362,7 +362,7 @@ describe("processor", () => {
const blocks = processor.preprocess(code);

assert.strictEqual(blocks[0].filename, "0.js");
assert.strictEqual(blocks[0].text, "var answer = 6 * 7;\nconsole.log(answer);\n");
assert.strictEqual(blocks[0].text, "var answer = 6 * 7;\r\nconsole.log(answer);\n");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is... strange. It says it "preserves" the original line endings, yet the assertion normalized them to \n. However, it was consistent. Here I see there's one \r\n and another \n. Any idea why that is? If v9 of the parser now preserves original line endings, I'd expect both to be \r\n. If this behavior changes, I'll want to add some autofix tests that span lines to make sure we're using correct substitutions. That'd be a likely place to have an off-by-one error that causes syntax errors in the output.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I agree it's weird. I think the last line of the code block is always normalized to \n, while the other line endings are preserved. It can be observed by adding another line inside the code block. Looks like an upstream issue.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no, it's actually due to this:

https://github.com/eslint/eslint-plugin-markdown/blob/f6a8ca0824b8a62d0af2a9eb512104564588b49e/lib/processor.js#L256-L260

It always adds a blank line and to the node value, and use \n without checking if it's relevant. I'm not sure why we add a blank line here…

For reference, here's the snippet I used to check the upstream implementation is working as expected:

console.log(
  require('mdast-util-from-markdown')([
    "```js",
    "var answer = 6 * 7;",
    "console.log(answer);",
    "```"
  ].join("\r\n")).children[0].value
); // 'var answer = 6 * 7;\r\nconsole.log(answer);'

});

it("should unindent space-indented code fences", () => {
Expand Down Expand Up @@ -646,8 +646,8 @@ describe("processor", () => {
const result = processor.postprocess(messages);

assert.strictEqual(result[2].column, 9);
assert.strictEqual(result[3].column, 2);
assert.strictEqual(result[4].column, 2);
assert.strictEqual(result[3].column, 4);
assert.strictEqual(result[4].column, 4);
});

it("should adjust fix range properties", () => {
Expand Down