Issue 1:
I'm tried to use *Profilter tool on Chrome browser, but i got this error when i review the rank of list Elements. I don't know what is that ?

DevTools version: 4.2.1-3816ae7c3

Call stack: at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:40:157108

at Map.forEach ()

at commitIndex (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:40:157054)

at e.getRankedChartData (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:40:157577)

at vl (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:40:314907)

at gi (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32:59907)

at jl (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32:107381)

at Lc (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32:92715)

at Pc (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32:92640)

at wc (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32:89544)

Component stack: in vl

in div

in div

in div

in wo

in Unknown

in n

in Unknown

in div

in div

in Li

in $e

in dn

in Ca

in Pc

Issue 2:
Should Do Soon

Having a package called react-native is weird.

Maybe we can just rename it to react-native-renderer to clarify the difference.

Better strategy for shared code?

Currently we just pile code into shared without particular structure, and then import directly through Haste. This is the same as we do in master though, so it’s at least no worse. We might want to tighten that up a little bit in the future, and maybe have some first-class entry points into it. We need to be clear shared code will be duplicated between any renderers using those modules.

Server shouldn't depend on reconciler modules.

I noticed warnValidStyle depends on ReactDebugCurrentFiber. This seems like it will always miss owner in warnings on server. Maybe it should depend on some other shared file instead? Regardless, this is already an issue on master so it’s not a regression.

Find a more solid way to avoid Jest skipping our own modules (current hack is gross).

The hack being "transformIgnorePatterns": ["/node_modules/(?!react)"], in package.json. Otherwise Jest skips our own code thinking it doesn’t need to be compiled because it was resolved through node_modules.

The hack is not dangerous and can’t cause false positives with third-party code because I specifically check the resolved symlink path in the Jest transformer. Still, it means that if we add a package whose name doesn’t start with react, it will not be Babel-ed in tests until we add another exceptional case there.

We can live with this hack for a little bit since we don’t plan to publish packages that don’t start with react in near future. We should file an issue with Jest though and come up with a better solution.

Update: fixed via #11372.

Should Do Later

Get rid of useFiber flag in bundle config

Rename entry points to be more intuitive (e.g. React should be React entry point etc)

Make internal folder structure more sensible

Move requires around to be prettier

Fix relative requires in tests

Get rid of fbEntry in bundle config

Why are we bundling lowPriorityWarning into PROD bundle?

In general, remove anything in bundle config that can now be determined using package folder

Fix the gross hack #11472

Forbid importing from other packages? #11303 (comment)

Move some Flow types

It is odd that package-level deps must be at top level too #11341 (comment)

Split bundle config per package and "autodiscover" packages for bundling and version check

Autogenerate "simple" entry point files for npm (react-dom/npm/index.js being the exception)

Move some of scripts into packages too?