jiebi/CodeConvo huggingface dataset:
Change:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React Dev Tools version: 4.6.0 I'm not sure there is a problem with within package, or it's just my misunderstand how it works, but script create production build. Command above runs a each script (per browser) in which is set to . run in creates minified version of files. where has set to . Each step in should be replaced from to
Send a PR? This does look odd.
Sure, I'll take a look at it tomorrow, it's looks odd and incorrectly but need to check there isn't any trap with that

Discussion:
"private": true, "scripts": { "build": "cross-env NODE_ENV=production yarn run build:chrome && yarn run build:firefox && yarn run build:edge", <del> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome && yarn run build:firefox && yarn run build:edge", </del> <ins> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome:dev && yarn run build:firefox:dev && yarn run build:edge:dev", </ins> "build:chrome": "cross-env NODE_ENV=production node ./chrome/build", "build:chrome:crx": "cross-env NODE_ENV=production node ./chrome/build --crx", "build:chrome:dev": "cross-env NODE_ENV=development node ./chrome/build",
Change:
Compare two screenshots closely. The space after "from" disappears when the next word is selected. <img width="574" alt="Screenshot 2020-04-07 at 13 26 40" src="https://user-"<img width="776" alt="Screenshot 2020-04-07 at 13 26 35" src="https://user-"
Oops. Yeah this looks like a CSS bug. Each row in the tree is . This means that gets smushed together in a way we don't want. Need to think about this for a minute.

Discussion:
.Wrapper { padding: 0 0.25rem; <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> height: var(--line-height-data); line-height: var(--line-height-data); display: inline-flex;
Change:
eslint yesterday. gets a peerDependency warning: Ensure compatibility with the newly released major and add to .
Oh I just realized is coming from another repo: Will open an issue there as well and edit this one.

Discussion:
}, "homepage": "https://reactjs.org/", "peerDependencies": { <del> "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0" </del> <ins> "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" </ins> }, "devDependencies": { "@typescript-eslint/parser": "^2.26.0"
Change:
This doesn't actually run any DevTools tests. It runs the main React tests. Console output shows that it's choosing the wrong config: I wonder if this is also happening for other targets?
It's because of this: DevTools uses both and

Discussion:
function getCommandArgs() { // Add the correct Jest config. const args = ['./scripts/jest/jest.js', '--config']; <del> if (argv.build) { </del> <ins> if (argv.project === 'devtools') { args.push(devToolsConfig); } else if (argv.build) { </ins> args.push(buildConfig); } else if (argv.persistent) { args.push(persistentConfig); <del> } else if (argv.project === 'devtools') { args.push(devToolsConfig); </del> } else if (isWWWConfig()) { args.push(wwwConfig); } else if (isOSSConfig()) {
Change:
React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!

Discussion:
* ${license} */ <del> 'use strict'; </del> ${source}`; },

* ${license} */ <del> ${source}`; </del> <ins> (function(){${source}})();`; </ins> }, /***************** UMD_PROFILING *****************/

* ${license} */ <del> ${source}`; </del> <ins> (function(){${source}})();`; </ins> }, /***************** NODE_DEV *****************/
Change:
It looks like the property inspector inside React DevTools is not rendering repeating spaces properly. I imagine this can result in some fairly frustrating debugging sessions when doing something like string matching a component that takes a string as a property. multiple spaces in a row to that property (I would type the actual spaces, but it appears Github truncates the extra spaces even inside the code snippet!) that element inside React DevTools. The value of the prop is rendered as The value of the prop should be rendered as Below are some screenshots of the behavior I'm seeing in production. Here's how the property value is rendered in inspector when it is output directly to the HTML: ! And here is how that same value is rendered inside DevTools: !
Looks like is our culprit. According to we just need to change that from to . I will try to test that and put up a PR if it works.
You're correct. Interested in contributing a patch for it? (If not, I'm happy to– but since you've already done the work I thought I'd ask.)
I would be more than happy to! I'll aim to have something up by this evening.
PR is up and ready for review!

Discussion:
.Value { color: var(--color-attribute-value); <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> overflow: hidden; text-overflow: ellipsis; cursor: default;
Change:
After updating react-dom to version 17 the build now includes () which isn't supported by ie11 without polyfilling. Coming from this line. Tested with just the default cra production build to make sure it wasn't a problem with my webpack config and the same issue. Tested using CRA on version 16.9.8 of react and react-dom which works with the production build for ie11.
Confirmed with https://csb-hznfc- (built from ) which errors with "SCRIPT438: Object doesn't support property or method 'fill'".
Any chance you could confirm the fix on a real IE
Gonna wait to see if a few more bugs get reported in the next few hours. Then will cut a patch.
Should be fixed in 17.0.1.

Discussion:
} export function createLaneMap<T>(initial: T): LaneMap<T> { <del> return new Array(TotalLanes).fill(initial); </del> <ins> // Intentionally pushing one by one. // https://v8.dev/blog/elements-kinds#avoid-creating-holes const laneMap = []; for (let i = 0; i < TotalLanes; i++) { laneMap.push(initial); } return laneMap; </ins> } export function markRootUpdated(
Change:
React version: . . Note the React peer dependency error. Notably, this currently affects (see ). will refuse to perform this installation entirely. peer-depends on whereas peer-depends on , which is generally considered a breaking change in a minor version. This might have been an oversight in how interacted with (It's considered a breaking change because a like the below should always result in a valid install.) Here are two potential solutions: Cut a release of that peer-depends on , strictly widening the peer dep range from that of 1.4.1. Cut a major release of that peer-depends on , and cut a release of that reverts its peer dependency to .
Happy to take a PR that fixes this by making the range more permissible. I think we need a bump after that to increase the major and simply keep 17-only. If you send a PR like this, please check if any of the other React packages had a similar problem with 17.
If you send a PR like this, please check if any of the other React packages had a similar problem with 17. Sure, I'll send a PR. I noticed a few similar cases in but they all seemed to be for "internal"/"experimental" packages: - - - - - Do you care about fixing any of these since they (AFAIK) don't really have public consumers?
(Retitling per your comment and my reply Sorry about that.)

Discussion:
"object-assign": "^4.1.1" }, "peerDependencies": { <del> "react": "^17.0.0" </del> <ins> "react": "^16.8.0 || ^17.0.0" </ins> }, "devDependencies": { "rxjs": "^5.5.6"
Change:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 17.0.1 the project: react dev tools and set the highlight updates when components render option. changes to the todos no updates are displayed via React dev tools <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --currently, updates are only displayed if the react component is not memoized. all react components should show their updates regardless of memoization.
any idea who I should ping to get some eyes on this?
No one needs to be pinged. We review GitHub issues as we have bandwidth. If you'd like to contribute a bug fix, those are welcome.
Sure, do you have an idea where I might look to investigate something like this? It would be my first time contributing to that code so it'd be greatly helpful if someone could point me in the general direction.
a start would be reading this Then you can read through the of the to get an idea of to start and debug the dev tools locally. Haven't submitted anything myself, but that's how I'd start.

Discussion:
if ( elementType === ElementTypeFunction || elementType === ElementTypeClass || <del> elementType === ElementTypeContext </del> <ins> elementType === ElementTypeContext || elementType === ElementTypeMemo || elementType === ElementTypeForwardRef </ins> ) { // Otherwise if this is a traced ancestor, flag for the nearest host descendant(s). traceNearestHostComponentUpdate = didFiberRender(
Change:
React version: 17.0.1 Setup eslint with as parser Cast a function passed to Link to code example: The following error was reported The rule should interpret the function argument correctly and know that it is already inline.
It looks like it is something that would be easy to support, but the question is: why would you do that?
Heh, a fair question. In my case, I needed it in order to support generics for a hook that helps manage state for asynchronous calls like mutations: Without the cast, TS doesn't know that the shape of the args object is the same. On the return statement, TS warns: This remains true even if I make the args a generic type too, so I think the issue is unavoidable.
TS is correct there. A function that has the same input type & return type as is not assignable to . might have other properties attached to it as well, which won't be attached to . For your particular situation, the type for can be a function that has the same argument & return types as , but should not be . Casting it as is lying to typescript.
Ahhh. Thanks With that hint I was able to fix my types and obviate the cast. That said, I would recommend keeping this issue open, since there will always be cases where folks will have to resort to casts like these, whether due to limitations in TS's expressiveness or (as in this case and I suspect most cases) one's ability to understand the type complexities and specify the types correctly. Sadly, not everyone has access to a to help them out when the types get complex.

Discussion:
} `, }, <ins> { code: normalizeIndent` function App(props) { React.useEffect((() => { console.log(props.test); }) as any, [props.test]); } `, }, </ins> ], invalid: [ {

isEffect, ); return; // Handled <ins> case 'TSAsExpression': visitFunctionWithDependencies( callback.expression, declaredDependenciesNode, reactiveHook, reactiveHookName, isEffect, ); return; // Handled </ins> case 'Identifier': if (!declaredDependenciesNode) { // No deps, no problems.
Change:
This is not important but it seems that this if statement is superfluous since always returns a string.
Yeah, looks like maybe this got broken during a refactor (). Actually since we check the type right above, maybe the condition should have just been deleted entirely. (I don't remember this code very well.)
Hey, I'm gonna pick this up and try to get a PR through to tidy this :) This would be my first issue in this repo. I've given the contribution guidelines a read through, and so will do my best to follow all the CoC and best practices in there.
This issue is all yours I've the "good first issue (taken)" label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let me know so that I can remove the label and free it up for someone else to claim. Cheers!
Hey! Raised a PR for this. Couldn't find any unit tests that covered the function here, and I started to write a few, but thought that it was probably out of scope of this PR. Can definitely create some tests for this function if needed though!

Discussion:
: data.constructor.name, }; <del> if (typeof data[Symbol.iterator]) { // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); } </del> <ins> // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); </ins> unserializable.push(path);
Change:
I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.

Discussion:
} .PrimitiveHookNumber { <del> color: var(--color-component-badge-count-inverted); background-color: var(--color-component-badge-background-inverted); </del> <ins> background-color: var(--color-primitive-hook-badge-background); color: var(--color-primitive-hook-badge-text); </ins> font-size: var(--font-size-monospace-small); margin-right: 0.25rem; border-radius: 0.125rem;

updateStyleHelper(theme, 'color-expand-collapse-toggle', documentElements); updateStyleHelper(theme, 'color-link', documentElements); updateStyleHelper(theme, 'color-modal-background', documentElements); <ins> updateStyleHelper( theme, 'color-primitive-hook-badge-background', documentElements, ); updateStyleHelper(theme, 'color-primitive-hook-badge-text', documentElements); </ins> updateStyleHelper(theme, 'color-record-active', documentElements); updateStyleHelper(theme, 'color-record-hover', documentElements); updateStyleHelper(theme, 'color-record-inactive', documentElements);

--light-color-expand-collapse-toggle: #777d88; --light-color-link: #0000ff; --light-color-modal-background: rgba(255, 255, 255, 0.75); <ins> --light-color-primitive-hook-badge-background: #e5e5e5; --light-color-primitive-hook-badge-text: #5f6673; </ins> --light-color-record-active: #fc3a4b; --light-color-record-hover: #3578e5; --light-color-record-inactive: #0088fa;

--dark-color-expand-collapse-toggle: #8f949d; --dark-color-link: #61dafb; --dark-color-modal-background: rgba(0, 0, 0, 0.75); <ins> --dark-color-primitive-hook-badge-background: rgba(0, 0, 0, 0.25); --dark-color-primitive-hook-badge-text: rgba(255, 255, 255, 0.7); </ins> --dark-color-record-active: #fc3a4b; --dark-color-record-hover: #a2e9fc; --dark-color-record-inactive: #61dafb;
Change:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 16.x <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Nothing. It's part of WAI-ARIA 1.3
I guess the question is what React considers a "valid" aria prop: specific version (range) of Aria version with a (WR,CR,PR,REC) spec editors consider the aria prop that ever existed
Yeah, it seems they've support for this fairly recently.
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” React isn’t the source of truth for that information. It sounds like the job of a linter rather than something react should warn about.
I think it might be from a compiler.
It's from here:
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” The reason is that they're often misspelled so on the whole it's beneficial to warn for unknown ones. I'll merge the PR.
Fixed by Will appear in 18.

Discussion:
<hr class="home-divider" /> <section class="home-bottom-section"> <div class="buttons-unit"> <del> <a href="/getting-started.html" class="button">Get Started</a> <a href="/download.html" class="button">Download React v{{site.react_version}}</a> </del> <ins> <a href="docs/getting-started.html" class="button">Get Started</a> <a href="downloads.html" class="button">Download React v{{site.react_version}}</a> </ins> </div> </section>
Change:
React version: 16.14.0, 17.0.2 aspectRatio via - no aspectRatio applied via className - aspectRatio applied Needs Chrome 79 or above: Link to code example: No aspectRatio rule applied: aspectRatio applied, here I'm adding it via a :
Yes, I have the same issue with another style property Basically I want to add or and it gets removed.
Try passing a string instead of number. React special cases numbers (to add the "px" suffix) and only doesn't for certain known attributes. So new ones sometimes need to be to this list if they shouldn't get a px suffix (most should):
Your issue is unrelated. Would you mind opening a separate issue for that thread? Basically try instead. I.e. double strings. It's confusing but CSS expects a JS string of a CSS string. This is similar to how you have to do in React but it's a little clearer there because it's a wrapper around it.
Thanks
how soon do you need this? Are you blocked?
no, no rush at all! Just something I stumbled upon. Thanks for the lightning-quick response though!

Discussion:
*/ export const isUnitlessNumber = { animationIterationCount: true, <ins> aspectRatio: true, </ins> borderImageOutset: true, borderImageSlice: true, borderImageWidth: true,
Change:
flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.

Discussion:
export function flushSync<A, R>(fn: A => R, a: A): R { const prevExecutionContext = executionContext; <del> if ((prevExecutionContext & (RenderContext | CommitContext)) !== NoContext) { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } return fn(a); } </del> executionContext |= BatchedContext; const previousPriority = getCurrentUpdatePriority();

// Flush the immediate callbacks that were scheduled during this batch. // Note that this will happen even if batchedUpdates is higher up // the stack. <del> flushSyncCallbackQueue(); </del> <ins> if ((executionContext & (RenderContext | CommitContext)) === NoContext) { flushSyncCallbackQueue(); } else { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } } </ins> } }

<ins> let React; let ReactNoop; let Scheduler; let useState; let useEffect; describe('ReactFlushSync', () => { beforeEach(() => { jest.resetModules(); React = require('react'); ReactNoop = require('react-noop-renderer'); Scheduler = require('scheduler'); useState = React.useState; useEffect = React.useEffect; }); function Text({text}) { Scheduler.unstable_yieldValue(text); return text; } test('changes priority of updates in useEffect', async () => { function App() { const [syncState, setSyncState] = useState(0); const [state, setState] = useState(0); useEffect(() => { if (syncState !== 1) { setState(1); ReactNoop.flushSync(() => setSyncState(1)); } }, [syncState, state]); return <Text text={`${syncState}, ${state}`} />; } const root = ReactNoop.createRoot(); await ReactNoop.act(async () => { root.render(<App />); // This will yield right before the passive effect fires expect(Scheduler).toFlushUntilNextPaint(['0, 0']); // The passive effect will schedule a sync update and a normal update. // They should commit in two separate batches. First the sync one. expect(() => expect(Scheduler).toFlushUntilNextPaint(['1, 0']), ).toErrorDev('flushSync was called from inside a lifecycle method'); // The remaining update is not sync ReactNoop.flushSync(); expect(Scheduler).toHaveYielded([]); // Now flush it. expect(Scheduler).toFlushUntilNextPaint(['1, 1']); }); expect(root).toMatchRenderedOutput('1, 1'); }); }); </ins>
Change:
We currently build DevTools to target Chrome 49 and Firefox 54. These are super old browser versions and they did not have full ES6 support, so the generated build is more bloated than it needs to be. DevTools uses most modern language features. Off the top of my head, the following features are used (basically everything but async and generator functions): The above min browser versions come from Assuming I'm not forgetting things, it looks like we'd need to target Chrome 60+ (released 2017-07-25) and Firefox 55+ (released 2017-04-18). This seems like a reasonable set of browsers to target. Interestingly enough, according to , but I think certain details (like spread in object literals) weren't included in the original spec and/or weren't until later. Note that we can't remove the IE 11 target from the backend yet due to Hermes (React Native) ES6 support but that should be doable by the end of the year given current engineering targets. But we could update the frontend target, as well as the targets for the extensions and the package. It would be good to increase the browser versions we target to at least the version numbers mentioned above, rebuild the DevTools, and compare bundle sizes and generated code.

Discussion:
"version": "4.10.1", "version_name": "4.10.1", <del> "minimum_chrome_version": "49", </del> <ins> "minimum_chrome_version": "60", </ins> "icons": { "16": "icons/16-production.png",

"applications": { "gecko": { "id": "@react-devtools", <del> "strict_min_version": "54.0" </del> <ins> "strict_min_version": "55.0" </ins> } },