-
Notifications
You must be signed in to change notification settings - Fork 22.5k
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
fix: syntax errors in JS example sections #18186
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Ahhh, I'm also looking into |
So you would prefer PRs in batches of 50 changed files? I've just checked and ~380 files have at least one syntax (parsing) error. |
Ah, let's spread them across 4 PRs then—about 100 lines of diff per PR would be the best. |
Just FYI: I'm planning to add a few more fixes to this PR before I open a new one |
Yes, our idea is to have a linter running periodically (or automatically, we'll see). For this to work, we need to run it once (like you do), find the errors, and fix them. Then we can run it weekly, and the weekly PR will be small enough to be reviewed quickly. |
You are welcome. |
@@ -19,7 +19,7 @@ The **`delete()`** method of the {{domxref("XRAnchor")}} interface removes an an | |||
## Syntax | |||
|
|||
```js | |||
delete() | |||
anchor.delete() |
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.
Not necessarily a syntax fix but this stops the parser from complaining since delete
is an operator.
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.
Yep—we do the same for generator.return()
. See also https://github.com/orgs/mdn/discussions/149
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.
No, we don't update these. We will change the type from js
to jssyntax
very soon. Meanwhile, we should ignore this one.
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.
Ugh... Maybe until we reach a resolution for https://github.com/orgs/mdn/discussions/148...
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.
I'm not sure whether you agreed on this change or want me to revert it. I'd appreciate an update
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.
Ugh... Maybe until we reach a resolution for https://github.com/orgs/mdn/discussions/148...
Yes, let's keep the original until this discussion is done (and the syntax section in the meta-docs).
Some things I'm noticing:
|
@@ -120,7 +120,7 @@ function openRequestedPopup() { | |||
|
|||
## Best practices | |||
|
|||
```js | |||
```html | |||
<script type="text/javascript"> |
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.
I think we should keep it js
and remove the <script>
element (3 times in this file)
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.
As those code blocks still include html, would you use a js
code block followed by a html
one?
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.
Yes, please.
We should rename those variables. |
Yes, variables (or pseudo-variables in syntax sections) that have problematic names should be replaced: people often cut and past these, and then modify (actually declaring the variable with the same name, etc.) |
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.
(See comments above)
5f0d73c
to
cb67bcc
Compare
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.
Thanks a lot. I'm really happy with the idea to use ESLint to find and fix syntax errors.
@lionralfs it would be great if you commit just the setup(no .md files) on a feature branch in your fork(or a PR here) and share with us. We need to have discussion about which rules to disable. For example, we need to disable |
We'll start by fixing syntax errors so that ESLint can work at all—and then negotiating with the parser about what to parse and what to report. For example I still strongly believe ```js
const a = 1;
// OR
const a = 2;
``` Is strictly better than two code blocks or using two identifiers, just to make the parser happy. Making this work probably requires tweaking the parser a bit. |
Oh btw, I think we can have |
I've pushed my ESLint setup to my fork: lionralfs:eslint-config |
Ok so here we go. PR #18442 is the fifth and last (for now) PR to fix syntax/parsing errors. As promised, I'll document all encountered issues that I've skipped here: List of remaining syntax parsing/errors
The .eslintignore file I've used to exclude all of these
|
Hi! I've created a discussion with the amazing list of errors you found. I grouped them into categories, problems, so that we can discuss them and find solutions: mdn/discussions#158 That way, we will have the discussion in one well-visible place rather than buried in PR. 🎉 Thanks a lot for this amazing work, @lionralfs! Much, much appreciated. 🎉 |
Summary
Hey everyone!
I've come across this modernization effort for JS code samples and decided to test the feasibility of using ESLint to automate some of the work. However, I've quickly noticed that around 500 code samples in the
files/en-us/web/api/
directory contain syntax errors (ESLint reports parsing errors). I then started to fix some of them, which is the state of this PR. Before proceeding to fix the remaining errors I wanted to ask for some maintainer input on whether this is worth pursuing. I imagine fixing everything in one big PR makes reviewing somewhat painful.I've purposely not commited my ESLint setup, but if you want to try it for yourself, this is how I did it:
npm install --save-dev eslint eslint-plugin-markdown
.eslintrc.js
:npx eslint "files/en-us/web/api/**/*.md"
Obviously this is not a perfect setup but it already highlights some existing issues with the code samples.
This PR…