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

Jump to bottom

docs: Remove trailing newline from the code of Playground links #17641

Merged
merged 2 commits into from Oct 13, 2023
Merged

docs: Remove trailing newline from the code of Playground links #17641

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
a1966b3
Remove trailing newline from Playground links
fasttime Oct 10, 2023
3d27544
Update as per discussion
fasttime Oct 12, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 5 additions & 1 deletion docs/.eleventy.js
View file
Open in desktop
Expand Up @@ -207,7 +207,11 @@ module.exports = function(eleventyConfig) {
// See https://github.com/eslint/eslint.org/blob/ac38ab41f99b89a8798d374f74e2cce01171be8b/src/playground/App.js#L44
const parserOptionsJSON = tokens[index].info?.split("correct ")[1]?.trim();
const parserOptions = { sourceType: "module", ...(parserOptionsJSON && JSON.parse(parserOptionsJSON)) };
const { content } = tokens[index + 1];

// Remove trailing newline and presentational `⏎` characters (https://github.com/eslint/eslint/issues/17627):
const content = tokens[index + 1].content
.replace(/\n$/u, "")
.replace(/⏎(?=\n)/gu, "");
const state = encodeToBase64(
JSON.stringify({
options: { parserOptions },
Expand Down
3 changes: 2 additions & 1 deletion docs/src/rules/eol-last.md
View file
Open in desktop
Expand Up @@ -42,7 +42,8 @@ Examples of **correct** code for this rule:

function doSomething() {
var foo = 2;
}\n
}

```

:::
Expand Down
37 changes: 10 additions & 27 deletions docs/src/rules/no-multiple-empty-lines.md
View file
Open in desktop
Expand Up @@ -59,13 +59,13 @@ Examples of **incorrect** code for this rule with the `{ max: 2, maxEOF: 0 }` op
::: incorrect

```js
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 0 }]*/

var foo = 5;


var bar = 3;

/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 0 }]*/⏎
⏎
var foo = 5;⏎
⏎
⏎
var bar = 3;⏎
⏎

```

Expand All @@ -75,36 +75,19 @@ Examples of **correct** code for this rule with the `{ max: 2, maxEOF: 0 }` opti

::: correct

```js
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 0 }]*/

var foo = 5;


var bar = 3;
```

:::

**Note**: Although this ensures zero empty lines at the EOF, most editors will still show one empty line at the end if the file ends with a line break, as illustrated below. There is no empty line at the end of a file after the last `\n`, although editors may show an additional line. A true additional line would be represented by `\n\n`.

**Incorrect**:

::: incorrect

```js
/*eslint no-multiple-empty-lines: ["error", { "max": 2, "maxEOF": 0 }]*/⏎
⏎
var foo = 5;⏎
⏎
⏎
var bar = 3;⏎
⏎

var bar = 3;
```

:::
Copy link
Member Author

Choose a reason for hiding this comment

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

After removing the ⏎ characters that are causing syntax errors, this code block becomes identical to the previous incorrect example block.

Copy link
Member

Choose a reason for hiding this comment

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

I think we should keep examples with ⏎. We could just remove ::: correct/::: incorrect.

Copy link
Member

Choose a reason for hiding this comment

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

And now that there's no extra \n, we could add another ::: correct example after the existing one (the one that ends on line 87), just with another \n so that it looks like the existing example + line 7 that appears as an empty line.

Copy link
Member Author

Choose a reason for hiding this comment

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

If we are going to replace <<TAB>> with a tab character in Playground links, maybe we could also replace ⏎ with an empty string (since there is already a newline), or use a more similar placeholder like <<NEWLINE>> or <<LINEBREAK>> to visually denote a newline where it makes sense for clarity, and remove those sequences in the code that gets passed to the Playground.

Then there could be just one code block that presents nicely in rule docs pages and has a functioning "Open in Playground" button. The intent is to avoid duplications (both in source code and in reading material, I guess).

Copy link
Member

Choose a reason for hiding this comment

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

If we are going to replace <> with a tab character in Playground links, maybe we could also replace ⏎ with an empty string (since there is already a newline), or use a more similar placeholder like <> or <> to visually denote a newline where it makes sense for clarity, and remove those sequences in the code that gets passed to the Playground.

I'd prefer to keep ::: correct and ::: incorrect, so I'd be in favor of replacing ⏎ with an empty string.

Copy link
Member

Choose a reason for hiding this comment

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

Replacing ⏎ with an empty string sounds good to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should keep at least one example code with ⏎ just for the understanding sake without making it a playground link or without ::: correct/::: incorrect

Copy link
Member Author

Choose a reason for hiding this comment

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

Hi @Tanujkanti4441, thanks for the feedback. I think the assumption here is that the ⏎ characters would be removed only from the code that gets passed to the Playground. They would remain visible in the code blocks on the documentation pages along with the correct/incorrect badge and the "Open in Playground" button. Does this sound like a viable solution to you?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes! This sounds great


**Note**: Although this ensures zero empty lines at the EOF, most editors will still show one empty line at the end if the file ends with a line break, as illustrated below. There is no empty line at the end of a file after the last `\n`, although editors may show an additional line. A true additional line would be represented by `\n\n`.

**Correct**:

::: correct
Expand Down