Previously, `createFileMap` split the MDX meta string on spaces and assumed the first token was the filename. Once we prefixed code fences with `{expectedErrors: ...}`, it would incorrectly parse the meta and crash.
This PR updates createFileMap to skip tokens in the meta containing a start and end brace pair (using a stack to ensure we close on the correct brace) while tokenizing the meta string as expected.
Test plan: pages reported in #7994 no longer crash on the next PR
Closes#7994
Reverts the revert now that we've fixed the bug. These pages should no longer crash:
/learn/referencing-values-with-refs
/learn/synchronizing-with-effects
/learn/separating-events-from-effects
/learn/removing-effect-dependencies
Previously, `createFileMap` split the MDX meta string on spaces and assumed the first token was the filename. Once we prefixed code fences with `{expectedErrors: …}`, it would incorrectly parse the meta and crash.
This PR updates createFileMap to skip tokens in the meta containing a start and end brace pair (using a stack to ensure we close on the correct brace) while tokenizing the meta string as expected.
I also added a fallback that was previously not handled if the filepath was undefined.
Test plan: pages reported in #7994 no longer crash on the next PR
Closes#7994
Reverts the revert now that we've fixed the bug. These pages should no longer crash:
/learn/referencing-values-with-refs
/learn/synchronizing-with-effects
/learn/separating-events-from-effects
/learn/removing-effect-dependencies
Previously, `createFileMap` split the MDX meta string on spaces and assumed the first token was the filename. Once we prefixed code fences with `{expectedErrors: …}`, it would incorrectly parse the meta and crash.
This PR updates createFileMap to skip tokens in the meta containing a start and end brace pair (using a stack to ensure we close on the correct brace) while tokenizing the meta string as expected.
Test plan: pages reported in #7994 no longer crash on the next PR
Closes#7994
Reverts the revert now that we've fixed the bug. These pages should no longer crash:
/learn/referencing-values-with-refs
/learn/synchronizing-with-effects
/learn/separating-events-from-effects
/learn/removing-effect-dependencies
Previously, `createFileMap` split the MDX meta string on spaces and assumed the first token was the filename. Once we prefixed code fences with `{expectedErrors: …}`, it would incorrectly parse the meta and crash.
This PR updates createFileMap to skip tokens in the meta containing a start and end brace pair (using a stack to ensure we close on the correct brace) while tokenizing the meta string as expected.
Test plan: pages reported in #7994 no longer crash on the next PR
Closes#7994
For local dev and CI we want to have the eslint-local-rules running, so let's make sure both have their dependencies installed. We don't use a monorepo setup here, which is why they're currently setup as a two completely independent yarn workspaces.
* Add local eslint rule to validate markdown codeblocks with React Compiler
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
* fix compiler errors
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
* Add copyright script
Copied over our copyright script from the react repo. I made a small fix to handle shebangs.
* Update copyright on all files
Run the script.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
In https://github.com/facebook/react/pull/34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
```ts
// pseudo type def
type MarkdownCodeBlockMetadata = {
expectedErrors?: {
'react-compiler'?: number[];
};
};
```
and can be used like so:
````
```js {expectedErrors: {'react-compiler': [4]}}
// ❌ setState directly in render
function Component({value}) {
const [count, setCount] = useState(0);
setCount(value); // error on L4
return <div>{count}</div>;
}
```
````
Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
I went through the list of existing errors and tried to separate the expected errors from those that seem to be flagging unexpected issues. In particular, our effects validations are flagging patterns that our own docs examples use. I added todos for these and will follow up later.
