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.

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

Prettier-ignore comments in .astro #26

Merged
merged 3 commits into from
Oct 7, 2021
Merged

Prettier-ignore comments in .astro #26

merged 3 commits into from
Oct 7, 2021

Conversation

drwpow
Copy link
Member

@drwpow drwpow commented Oct 6, 2021

Changes

Gets <!-- prettier-ignore --> comments working in .astro.

There are probably more changes here than expected. Basically, the comment handling set off a few changes:

  1. Handle comments in Prettier
  2. Because comments were handled, Prettier can now manage whitespace around them (and can move them when needed).
  3. Because Prettier now manages whitespace around comments differently, some of the hardlines we were inserting between documents had to be adjusted, and removed
  4. Because I fiddled with the hardlines between documents, I ended up with extra whitespace within markdown codeblocks which count as separate “documents” (such as no double-line break between the end of --- and the first line of HTML).

I also made a few other whitespace changes that I can’t explain but they pass tests 🤷🏻

Testing

Tests should pass!

Docs

getText,
isObjEmpty,
trimTextNodeLeft,
trimTextNodeRight,
Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry for noise; I just alphabetized these (and in a couple other places) to see what’s being imported/exported better.

@@ -44,7 +47,7 @@ const {
* @param {import('prettier').Parseropts<any>} opts
* @param {(path: import('prettier').AstPath<any>) => import('prettier').Doc} print
*/
const printTopLevelParts = (node, path, opts, print) => {
function printTopLevelParts(node, path, opts, print) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Minor cleanup: trying to make everything consistent.

@@ -138,40 +152,43 @@ const print = (path, opts, print) => {
return group(path.map(print, 'children'));
}
}
case 'Text':
if (!isPreTagContent(path)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

This logic isn’t changed at all; I just flattened the if statements to be a little more readable as I was debugging this behavior.

@@ -528,37 +527,67 @@ const isObjEmpty = (obj) => {
return true;
};

/** Recursively attach comments to nodes */
function attachCommentsHTML(node) {
Copy link
Member Author

Choose a reason for hiding this comment

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

The core of this PR

}
}

// remove arbitrary whitespace nodes
Copy link
Member Author

Choose a reason for hiding this comment

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

I found this behavior necessary because Prettier kept trying to preserve the whitespace between the actual Prettier comment and the node it was attached to. But despite moving whitespace around, Prettier seemed to rearrange everything correctly in the following pass when it processes the comment

@@ -5,14 +5,7 @@
<!-- prettier-ignore -->
<div class="x">Two</div>

<!-- prettier-ignore-attribute -->
Copy link
Member Author

Choose a reason for hiding this comment

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

These weren’t even working in the Playground! ☹️ So removed.

@@ -2,5 +2,4 @@
const style = "color:red;";
let id = "#aloha";
---

Copy link
Member Author

@drwpow drwpow Oct 6, 2021

Choose a reason for hiding this comment

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

These extra linebreaks were removed from our printer adding linebreaks between “documents” (with the code fence & HTML being treated as 2 documents).

If we want a line break back here, I think we should add it as the first child of the HTML document only in that instance; otherwise unconditionally adding linebreaks between documents sometimes results in too much whitespace when the full document is reassembled.

Copy link
Collaborator

Choose a reason for hiding this comment

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

These newlines were intentional!

I think softline should be the solution to our problem, since it does as you suggest, collapsing to zero whitespace when unneeded.

Copy link
Member Author

Choose a reason for hiding this comment

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

I can give softline a try

@@ -64,18 +67,18 @@ const printTopLevelParts = (node, path, opts, print) => {
}

const docs = flatten([parts.frontmatter, ...parseSortOrder(opts.astroSortOrder).map((p) => parts[p])]).filter((doc) => '' !== doc);
return group([join(hardline, docs)]);
Copy link
Member Author

Choose a reason for hiding this comment

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

Removing the hardline cut down on too much whitespace in areas (see prev. comment).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this be changed to a softline rather than removing it entirely? The intention is to have a single newline of space between top-level parts of an Astro file

Copy link
Member Author

Choose a reason for hiding this comment

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

I found when prettier reassembles the docs, it automatically adds lines on its own. When I add hardline or softline here it just results in a double-space between --- and the first line of HTML.

If that’s the style I can change it back! It just didn’t seem like that‘s what we’re going for from the existing output tests.

But I might be missing something, or there might be a better way to do it. TBH I’m confused on when Prettier does inject a new line at the end of a document; I just know I had to use stripTrailingHardline() in places.

Copy link
Member Author

Choose a reason for hiding this comment

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

See #31

@jasikpark
Copy link
Collaborator

hopefully adding support for embedded formatting to codespans will fix that so that you don't exactly need that context?

@drwpow drwpow force-pushed the prettier-html-comment branch from 58587fd to 81d86a3 Compare October 6, 2021 23:26
@drwpow drwpow marked this pull request as ready for review October 6, 2021 23:26
@drwpow
Copy link
Member Author

drwpow commented Oct 6, 2021

hopefully adding support for embedded formatting to codespans will fix that so that you don't exactly need that context?

Yeah I think so! I was able to hack it with opts.parentParser === 'markdown' but other than that, I can’t tell what’s actually a top-level Astro file (comments should be respected) vs a nested code block within markdown (comments should be ignored).

@drwpow drwpow changed the title [wip] Prettier-ignore comments in .astro Prettier-ignore comments in .astro Oct 6, 2021
@drwpow drwpow requested a review from jasikpark October 6, 2021 23:38
@drwpow drwpow merged commit 8b86f7d into main Oct 7, 2021
@drwpow drwpow deleted the prettier-html-comment branch October 7, 2021 16:28
Copy link
Collaborator

@jasikpark jasikpark left a comment

Choose a reason for hiding this comment

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

Sorry for the late, post-merge review, but I have a few comments. I didn't realize how many changes were occurring in this one PR!

@@ -1,5 +1,5 @@
{
"ignorePatterns": ["test/fixures/**"],
Copy link
Collaborator

Choose a reason for hiding this comment

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

I had this setup to intentionally be linting our test files as well, this change prevents plugin:ava/reccomended from being useful. Could we revert this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

I can revert that. I would just have to add an .eslintrc file to set a few rules differently for tests (for example, the current ESLint doesn’t like when you import devDependencies).

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh, is it complaining about importing ava? maybe we can turn that rule off for the specific places we import from a devdependency?

@@ -64,18 +67,18 @@ const printTopLevelParts = (node, path, opts, print) => {
}

const docs = flatten([parts.frontmatter, ...parseSortOrder(opts.astroSortOrder).map((p) => parts[p])]).filter((doc) => '' !== doc);
return group([join(hardline, docs)]);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this be changed to a softline rather than removing it entirely? The intention is to have a single newline of space between top-level parts of an Astro file

@@ -451,20 +473,25 @@ const embed = (path, print, textToDoc, opts) => {
return textToDoc(node.content, { ...opts, parser: 'html' });
}

return null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a reason to choose between returning null and "" here? I think there's one or two other places to change it if this improves things.

Copy link
Member Author

Choose a reason for hiding this comment

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

TBH I was a bit confused on this. I found that returning null in certain places broke the printer, so I just assumed that there was a problem with it. But it may just be a problem with our own printer! I can revert this.

@@ -171,7 +170,7 @@ function printRaw(node, originalText, stripLeadingAndTrailingNewline = false) {
}

function isNodeWithChildren(node) {
return !!node.children;
return node && Array.isArray(node.children);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Good change! Will children always be an array?

Copy link
Member Author

Choose a reason for hiding this comment

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

It should be. This is more just protection because anything can maniplate the ast.


const nodesToRemove = [];

// note: the .length - 1 is because we don’t need to read the last node
Copy link
Collaborator

Choose a reason for hiding this comment

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

what does this mean? Isn't length - 1 normal syntax to read the entirety of a list? Wouldn't you need length - 2 to ignore the last node?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah yeah that’s confusing. < node.children.length reaches the end so < node.children.length - 1 stops 1 short. Can change to make this simpler.

Copy link
Collaborator

Choose a reason for hiding this comment

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

ope lol i missed that bit..

@@ -2,5 +2,4 @@
const style = "color:red;";
let id = "#aloha";
---

Copy link
Collaborator

Choose a reason for hiding this comment

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

These newlines were intentional!

I think softline should be the solution to our problem, since it does as you suggest, collapsing to zero whitespace when unneeded.

@drwpow
Copy link
Member Author

drwpow commented Oct 8, 2021

Sorry for the late, post-merge review, but I have a few comments. I didn't realize how many changes were occurring in this one PR!

Please! Comments welcome. Will address all these in a follow-up, and happy to address anything else you find. I just didn’t want to put a full review on you. Happy to change anything here.

@drwpow drwpow mentioned this pull request Oct 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants