Don't minify symbols in production builds #28881
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
React Core Team
acdlite
force-pushed
the
dont-minify-symbols
branch
2 times, most recently
from
9f02628
to
c4f36e8
Compare
|
The size diff is too large to display in a single comment. The CircleCI job contains an artifact called 'sizebot-message.md' with the full message. |
acdlite
force-pushed
the
dont-minify-symbols
branch
from
c4f36e8
to
001602f
Compare
This disables symbol renaming in production builds. The original variable and function names are preserved. All other forms of compression applied by Closure (dead code elimination, inlining, etc) are unchanged — the final program is identical to what we were producing before, just in a more readable form. The motivation is to make it easier to debug React issues that only occur in production — the same reason we decided to start shipping sourcemaps in facebook#28827 and facebook#28827. However, because most apps run their own minification step on their npm dependencies, it's not necessary for us to minify the symbols before publishing — it'll be handled the app, if desired. This is the same strategy Meta has used to ship React for years. The React build itself has unminified symbols, but they get minified as part of Meta's regular build pipeline. Even if an app does not minify their npm dependencies, gzip covers most of the cost of symbol renaming anyway. This saves us from having to ship sourcemaps, which means even apps that don't have sourcemaps configured will be able to debug the React build as easily as they would any other npm dependency.
acdlite
force-pushed
the
dont-minify-symbols
branch
from
001602f
to
e625cd8
Compare
sebmarkbage
approved these changes
Apr 19, 2024
github-actions bot
pushed a commit
that referenced
this pull request
Apr 20, 2024
This disables symbol renaming in production builds. The original variable and function names are preserved. All other forms of compression applied by Closure (dead code elimination, inlining, etc) are unchanged — the final program is identical to what we were producing before, just in a more readable form. The motivation is to make it easier to debug React issues that only occur in production — the same reason we decided to start shipping sourcemaps in #28827 and #28827. However, because most apps run their own minification step on their npm dependencies, it's not necessary for us to minify the symbols before publishing — it'll be handled the app, if desired. This is the same strategy Meta has used to ship React for years. The React build itself has unminified symbols, but they get minified as part of Meta's regular build pipeline. Even if an app does not minify their npm dependencies, gzip covers most of the cost of symbol renaming anyway. This saves us from having to ship sourcemaps, which means even apps that don't have sourcemaps configured will be able to debug the React build as easily as they would any other npm dependency. DiffTrain build for [857ee8c](857ee8c)
unstubbable
added a commit
to unstubbable/next.js
that referenced
this pull request
Apr 20, 2024
This can be reverted when a React canary version is used that includes facebook/react#28881.
eps1lon
added a commit
to vercel/next.js
that referenced
this pull request
Apr 21, 2024
commit ea37c04 Author: Hendrik Liebau <[email protected]> Date: Wed Apr 17 21:59:01 2024 +0200 Fix vscode launch configs to allow setting breakpoints in the IDE commit 47fe8e8 Author: Hendrik Liebau <[email protected]> Date: Sat Apr 20 21:23:37 2024 +0200 Add and load React production source maps This can be reverted when a React canary version is used that includes facebook/react#28881. commit c8f3798 Author: Hendrik Liebau <[email protected]> Date: Sat Apr 20 21:18:35 2024 +0200 Inline Next.js sources content into source map files This avoids a `loadNetworkResource` error in Chrome DevTools when trying to set breakpoints in the Next.js sources, for both server and client. commit c286c02 Author: Tim Neutkens <[email protected]> Date: Sat Apr 20 15:45:35 2024 +0200 Disable ncc cache instead of cache cleaning (#64804) `ncc cache clean` is running each time we call `ncc-compiled`. This PR removes the cache cleaning and instead just always passes `cache: false` to disable the built-in ncc cache. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change Closes NEXT- Fixes # --> Closes NEXT-3174 commit b914ad8 Author: Zack Tanner <[email protected]> Date: Fri Apr 19 18:11:32 2024 -0600 fix interception route rewrite regex not supporting hyphenated segments (#64805) The function we use to generate a string with named parameters to pass into `path-to-regexp` currently doesn't properly handle non-word characters (namely, for the purposes of this bugfix, hyphens). As a result, `pathToRegexp` will convert something like `/foo/:bar-baz` into `/^\/foo(?:\/([^\/#\?]+?))-baz[\/#\?]?$/i`, effectively only treating the `:foo` as part of the regex capture group and leaving a dangling -baz. This means using an interception route within a dynamic segment (such as `/foo/[bar-baz]`) would not properly trigger the route interception Fixes #64766 commit 02e5f65 Author: vercel-release-bot <[email protected]> Date: Fri Apr 19 23:23:22 2024 +0000 v14.3.0-canary.13 commit c1ca6ac Author: Jeffrey Zutt <[email protected]> Date: Sat Apr 20 01:13:58 2024 +0200 fix: remove traceparent from cachekey should not remove traceparent from original object (#64727) I submitted PR #64499 , it got merged, but it contains a mistake. I'm terribly sorry about this! By removing the traceparent from the cachekey, we mistakenly removed the header from the original object. Causing the actual request to be executed without the traceparent header. Creating a cachekey should not alter the original object. Flip the arguments for Object.assign --------- Co-authored-by: Jeffrey <[email protected]> Co-authored-by: JJ Kasper <[email protected]> commit ea0f516 Author: Sean O'Neil <[email protected]> Date: Fri Apr 19 15:43:26 2024 -0500 Update 06-bundle-analyzer.mdx (#64740) The[ existing code example](https://nextjs.org/docs/app/building-your-application/optimizing/bundle-analyzer) generates the following warning when using `--turbo` in the current latest version of NextJS (14.2.2): ⚠ Webpack is configured while Turbopack is not, which may cause problems. ⚠ See instructions if you need to configure Turbopack: https://nextjs.org/docs/app/api-reference/next-config-js/turbo This modification ensures that the bundle analyzer is only applied when the user intends to generate a report. Fixes # #64739 --------- Co-authored-by: Lee Robinson <[email protected]> Co-authored-by: Maxim Svetlakov <[email protected]> Co-authored-by: JJ Kasper <[email protected]> commit cf038a3 Author: Steven Primeaux <[email protected]> Date: Fri Apr 19 14:36:25 2024 -0400 docs: "generateMetadata" to "generateViewport" in doc "generateViewport" (#64795) Changed "generateMetadata" to "generateViewport" in generate-viewport.mdx Co-authored-by: Sam Ko <[email protected]> commit a0f334c Author: Kushagra Sharma <[email protected]> Date: Sat Apr 20 00:04:21 2024 +0530 Update index.mdx (#64794) Removed a type annotation from a code block <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change Closes NEXT- Fixes # --> commit bd6ab04 Author: Tim Neutkens <[email protected]> Date: Fri Apr 19 20:26:54 2024 +0200 Upgrade Turborepo (#64767) Upgrade Turborepo to the latest version and enable the new terminal UI to dogfood: https://turbo.build/blog/turbo-1-13-0#new-terminal-ui. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change Closes NEXT- Fixes # --> Closes NEXT-3164
This was referenced Apr 24, 2024
|
Hey, @acdlite . Any chance of reconsidering shipping sourcemaps? The main issue I'm seeing with looking at some of the prod artifacts is that all the Closure function inlining in the production artifacts is making it harder to actually understand what the original React code actually looked like, as well as things like constant flags being turned into integers. Having the prod artifact be readable is a huge step in the right direction, but the optimized code deviates enough from the original source that it can still be pretty tricky to dig through. |
Sourcemaps don't help with inlined functions: tc39/source-map#40 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This disables symbol renaming in production builds. The original variable and function names are preserved. All other forms of compression applied by Closure (dead code elimination, inlining, etc) are unchanged — the final program is identical to what we were producing before, just in a more readable form.
The motivation is to make it easier to debug React issues that only occur in production — the same reason we decided to start shipping sourcemaps in #28827 and #28827.
However, because most apps run their own minification step on their npm dependencies, it's not necessary for us to minify the symbols before publishing — it'll be handled the app, if desired.
This is the same strategy Meta has used to ship React for years. The React build itself has unminified symbols, but they get minified as part of Meta's regular build pipeline.
Even if an app does not minify their npm dependencies, gzip covers most of the cost of symbol renaming anyway.
This saves us from having to ship sourcemaps, which means even apps that don't have sourcemaps configured will be able to debug the React build as easily as they would any other npm dependency.