~~I want to propose the addition of a new file in the `react-dom` npm package called `react-dom.production.js` — a non-minified version of `react-dom` production build.~~

Edit: After some discussion(see below) it seems that distributing source maps makes more sense. Source maps will help you see the real function names and explore them. (The points below apply for source maps as well.)

## Why?

There are a few ways to profile React's performance — none of them provide a low-level view of what's happening. I believe the best way to profile React is using Chrome's Performance tab using a non-minified production build. Here's why:
- **Familiar.** People use the Performance tab for every other performance profiling so they are familiar with how to use it.
- **Powerful.** The Performance tab is extremely powerful. Years of engineering have been put into developing it.
- **Better understanding.** When using the React DevTools profiler I have a common problem – I see a component being rendered slowly but I don't know what is causing it. In order to understand I need a more low-level view. Here are some questions that can be answered only with the Chrome Performance tab:
    - What's the balance between the app's code and React execution times? Should I implement some frequently updated components using custom non-React implementation?
    - What time is spend on setting attribute values, setting `innerHTML` and adding and removing listeners?
    - What time is spent on disposing effects? Is there a specific dispose function that is taking more than usual?
    - What time is spent on mounting effects? Is there a specific effect mount that is taking more than usual?

## Disadvantages

As with every solution, there are some drawbacks to using this approach:
- **Documentation needed.** In order to make sense of what's happening you will need some knowledge of the core functions in React. A little guide with the names of the functions for mount/unmount, effects, and DOM manipulations will be useful. This of course can be done by the community(you are already linking to some community posts in React's documentation).
- **Requires more skill.** This isn't for everybody. It's aimed at more experienced developers. This type of profiling is a lot more overwhelming than the current approach.
- **May not fit your principles.** Maybe it's not part of your principles to introduce and promote such a complicated solution. Maybe you are more interested in searching for a more elegant and minimal solution.
moduleType,
  pureExternalModules,
  bundle
) {
  try {
    const forks = Modules.getForks(bundleType, entry, moduleType, bundle);
    const isProduction = isProductionBundleType(bundleType);
    const isProfiling = isProfilingBundleType(bundleType);
    const isUMDBundle =
      bundleType === UMD_DEV ||
      bundleType === UMD_PROD ||
      bundleType === UMD_PROFILING;
    const isFBWWWBundle =
      bundleType === FB_WWW_DEV ||
      bundleType === FB_WWW_PROD ||
      bundleType === FB_WWW_PROFILING;
    const isRNBundle =
      bundleType === RN_OSS_DEV ||
      bundleType === RN_OSS_PROD ||
      bundleType === RN_OSS_PROFILING ||
      bundleType === RN_FB_DEV ||
      bundleType === RN_FB_PROD ||
      bundleType === RN_FB_PROFILING;
    const shouldStayReadable = isFBWWWBundle || isRNBundle || forcePrettyOutput;
    return [
      
      dynamicImports(),
      {
        name: 'rollup-plugin-flow-remove-types',
        transform(code) {