New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't minify symbols in production builds #28881
Merged
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
Opened by a member of the React Core Team
labels
Apr 19, 2024
acdlite
force-pushed
the
dont-minify-symbols
branch
2 times, most recently
from
April 19, 2024 19:40
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
April 19, 2024 19:57
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
April 19, 2024 19:59
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 <mail@hendrik-liebau.de> 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 <mail@hendrik-liebau.de> 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 <mail@hendrik-liebau.de> 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 <tim@timneutkens.nl> 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 <1939140+ztanner@users.noreply.github.com> 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 <infra+release@vercel.com> Date: Fri Apr 19 23:23:22 2024 +0000 v14.3.0-canary.13 commit c1ca6ac Author: Jeffrey Zutt <jeffrey@hang-out.nl> 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 <jeffrey@jeffreyzutt.nl> Co-authored-by: JJ Kasper <jj@jjsweb.site> commit ea0f516 Author: Sean O'Neil <59893658+sean-rallycry@users.noreply.github.com> 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 <me@leerob.io> Co-authored-by: Maxim Svetlakov <maxim@ebookapplications.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> commit cf038a3 Author: Steven Primeaux <58159084+Auxdible@users.noreply.github.com> 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 <sam@vercel.com> commit a0f334c Author: Kushagra Sharma <162145291+IAmKushagraSharma@users.noreply.github.com> 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 <tim@timneutkens.nl> 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
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.