Skip to content

[pull] canary from vercel:canary #568

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

Merged
merged 7,797 commits into from
Feb 18, 2025
Merged

[pull] canary from vercel:canary #568

merged 7,797 commits into from
Feb 18, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 8, 2024

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot requested a review from timneutkens as a code owner February 8, 2024 01:29
@pull pull bot added the ⤵️ pull label Feb 8, 2024
sokra and others added 28 commits February 5, 2025 01:15
### What?

This changes to order of operations to upper aggregation numbers before connecting children, so they can be added based on the new aggregation numbers.
### What?

Use `swc_atoms::Atom` instead of `String` in `next-swc`. 

### Why?

`Atom` does not allocate if another instance has the same value, meaning that `clone()` is a single atomic operation. But `String` allocates regardless of any other occurrence.
### What?

Use `swc_atoms::Atom` instead of `String` in `next-swc`. 

### Why?

`Atom` does not allocate if another instance has the same value, meaning that `clone()` is a single atomic operation. But `String` allocates regardless of any other occurrence.
…5437)

### What?

Skip some methods for tasks without children.

Reduces number of spans created in tracing.
…75438)

### What?

Allow to continue follow-up tasks even if a task is not completely finished. It can do task completion work in background.

This enables more concurrency, especially since all task connecting is at the end of the task now.
### What?

Remove one allocation per `transform()` and `minify()`.

### Why?

We don't need to allocate `Compiler` in an `Arc`, because we don't share it.
This PR adds a lot of polish to the experimental Error Overlay:


https://github.com/user-attachments/assets/2540b966-c61d-43eb-b816-5ef25f3ecb11

### Motion
- Stacked layers transition smoothly when switching between errors
- Height transition for the dialog panel to complement the stacked
layers transition
- Dialog contents and the backdrop fade in as per Geist Motion
Guidelines (`scale`, `opacity`)

### Design
- New language icon based on file extension à la (`app.tsx`)
- Shadows are clipped with translucent borders to visually be more crisp
- Use `backdrop-filter: blur()` for backdrop to blend with application
content
- Use `font-variant-numeric: tabular-nums` for ←→ switcher to avoid
layout shift
- Misc alignment improvements

### Interactions
- Focus is now trapped in the dialog, <kbd>Escape</kbd> will un-trap and
re-focus the last `root.activeElement`
- Focus states for all interactive elements
- Fluid reveal & collapse of ignored Call Stack items ↓




https://github.com/user-attachments/assets/59a81cea-24ec-4fe4-be00-b911ab484757

Closes NDX-711
Closes NDX-744

---------

Co-authored-by: devjiwonchoi <[email protected]>
Co-authored-by: Zack Tanner <[email protected]>
Meaning fewer cells and fewer tasks

No measureable perf difference
AFAICT, Next.js doesn't do this either
and this seems to solve this error
```
thread '<unnamed>' panicked at turbopack/crates/turbo-tasks-backend/src/backend/mod.rs:949:13:
Dependency tracking is disabled so invalidation is not allowed

thread 'tokio-runtime-worker' panicked at turbopack/crates/turbo-tasks-fs/src/lib.rs:265:63:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }
```
This might make a difference if the `RequireContextMap` is huge and used
across many files

More importantly, this seems to solve this failure in the testing
backend on #75440:

```
called 'Result::unwrap()' on an 'Err' value: Cell is empty
Stack backtrace:
0: <anyhow::Error>::msg::<&str>
1: <turbo_tasks::backend::TypedCellContent>::cast::<turbopack_emascript::analyzer::RequireContextValue>
2: <turbo_tasks::vc::read::ReadVcFuture<turbopack_ecmascript::analyzer::RequireContextValue> as core::future::future::Future>::poll
3: turbopack_ecmascript::analyzer::well_known::replace_well_known::{closure#0}
4: turbopack_ecmascript::analyzer::linker::visit::<mod::analyzer::bench_link::{closure#0}::{closure#0}::{closure#0}::{closure#0}, turbopack_emascript: analyzer: it {closure#0}>::{closure#0}
```
Maintain a cache of `VariableId -> JsValue` (per-module), so that we
don't reevaluate variables (mostly, unless it's a local variable inside
a function call)

```
canary 8202690:
15,3gb
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  501.72s user 108.30s system 760% cpu 1:20.26 total
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  502.01s user 102.27s system 774% cpu 1:18.04 total

mischnic/analyzer-link-cache 66d7e1f:
15,3gb
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  490.36s user 104.63s system 731% cpu 1:21.34 total
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  489.22s user 106.89s system 780% cpu 1:16.39 total
```
Disambiguate `TaskInput::resolve` from `Vc::resolve` and `ResolvedVc::resolve`.

Turns out there was only a single instance where `resolve()` turned out to be the wrong function anyway...
### What?

ChangeLog:
swc-project/swc@[email protected][email protected]

### Why?


 - To keep in sync
 - To drop `rustc-hash` v1
 - To apply swc-project/swc#9978

---------

Co-authored-by: Niklas Mischkulnig <[email protected]>
…#75507)

When adding or removing a `"use cache"` directive to a function or
module, Turbopack was not able to finish the compilation and hung. This
is now fixed, and we're adding the test to prevent regression.
…f local tasks we ended up not using) (#75672)

Local cells would allow us to avoid allocating real cells for data
passed to local task functions.

Unfortunately, in practice, we manually resolve most arguments passed to
local task functions, which would defeat this optimization.

I was holding onto this in the hopes that we might end up using it, but
that seems fleeting:
- We could get similar benefits by scanning for unreferenced cells at
the end of function execution using `TraceRawVcs` at the cost of a bit
of execution time. This would work even on `Vc`s that were resolved.
- For ergonomics reasons, we want to eventually rename `ResolvedVc` to
`Vc` (and `Vc` to something like `UnresolvedVc`), which will probably
lead to us resolving even more stuff, breaking this potential
optimization even more.
- Cache eviction may do a good enough job of removing cells, the bigger
enemy are the harder-to-evict tasks, which our current version of local
tasks does do a good job of reducing.

Meanwhile, it makes the code harder to follow, and could cause issues if
this codepath somehow got activated.
Don't even evaluate the left side of `obj.prop` if we know that we don't have anything in the replacement maps that matches  `*.prop` anyway.

This particular helps in huge files with complex code and also containing many member expressions

```
testing against 0293c96cf32

canary b6f8743
13,75 GB 
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  507.86s user 77.80s system 847% cpu 1:09.11 total
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  503.13s user 77.86s system 855% cpu 1:07.90 total


mischnic/analyzer-faster-members ed38e94ba2
13,75 GB 
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  499.54s user 79.28s system 857% cpu 1:07.51 total
TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD=  498.31s user 76.99s system 855% cpu 1:07.27 total
```
Seems this was failing in #75693
This is a follow-up to #75624
which ensures middleware behaves correctly in the `src/` directory. This
previously wasn't an issue since edge runtime output location isn't
picky since it's just output in the middleware-manifest although with
node runtime it is particular.
### What?

fix a previous PR that disables dependency tracking when not needed.
…ite (#75681)

This allows us to catch regressions and monitor progress (e.g. for NAR-85).

In addition, we're consolidating all pages in the test app to use a single root layout without a suspense boundary. Before we switched the app from using the `dynamicIO` flag to the `useCache` flag, some pages needed a suspense boundary to not fail the build.
napi-rs only uses the cdylib version: https://github.com/napi-rs/napi-rs/blob/688a266f132f947b8002e892b78decd660d8a6ec/crates/napi/README.md#building

This might(?) slightly improve compile times for certain invocations of `cargo`.
…75662)

When `dynamicIO` is not enabled, and only the standalone `useCache`
experimental flag is enabled, we can not encode `searchParams` as
hanging promises. To still avoid unused search params from making a page
dynamic (due to the `searchParams` being encoded into the cache key), we
set them to a promise that resolves to an empty object, while also
overwriting the to-be-invoked function for generating a cache entry with
a function that creates an erroring `searchParams` prop before invoking
the original function. This ensures that used `searchParams` inside of
cached functions would still yield an error.

closes NAR-85
unstubbable and others added 29 commits February 17, 2025 12:15
Follow-up for #74674

When running `pnpm next build` or `pnpm next dev` with a test app in the
Next.js repo, we patch the app's `tsconfig.json` to exclude the test
files from the program, because those are already covered by the root
`tsconfig.json`.

The code to suppress logging this action had a bug where we tried to
remove the action from the list of `requiredActions` even if it wasn't
added, resulting in the following runtime error:

```
Cannot read properties of undefined (reading 'includes')
```

This could happen when the `requiredActions` array was empty but the
`suggestedActions` array was not.
…6077)

### What?

This PR uses the `devIndicators.position` option to set the position of the dev indicator.
The default option is changed from `"bottom-right"` to `"bottom-left"` to sync the previous dev indicator behavior, but have covered backward compatibility for the default position of old overlay's build activity indicator.

### Success Criteria

- [x] Does setting `buildActivityPosition` correctly set the dev indicator position?
- [x] Does setting the `position` correctly set the dev indicator position?
- [x] Does it default to `"bottom-left"`?
- [x] Does the dev indicator popover display properly based on the `position`?

Backwards Compatible:

> Are there any breaking changes?

- [x]  Is the position `"bottom-right"` on the old overlay if the user hasn't set the `position`?
- [x] Is the position `"bottom-right"` on the old overlay if the user hasn't set the `buildActivityPosition`?
- [x] Does the position follow the `position` option?
- [x] Does the position follow the `buildActivityPosition` option?

https://github.com/user-attachments/assets/a5dba705-1b9d-4470-80e6-1952b22c2f46

Closes NDX-838
### What?

 - Do not run react compiler for files in `node_modules`.
 - When the react compiler is not enabled, just disable Babel.

### Why?

We were stripping TypeScript and JSX using Babel when the React Compiler was enabled. We don't have to, and we should not.
Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>
Run `EsmAssetReference::code_generation` without cells/turbo tasks.

```
testing against 0293c96cf32


canary 71d8bfc
14.8gb
529.67s user 81.57s system 883% cpu 1:09.18 total

mischnic/codegen-fewer-tasks 72eba1e
14.8gb
533.13s user 82.01s system 874% cpu 1:10.32 total

mischnic/codegen-fewer-tasks don't store twice
14.6gb
529.85s user 82.35s system 875% cpu 1:09.90 total

mischnic/codegen-esm-asset
14.2gb
528.69s user 81.37s system 881% cpu 1:09.17 total
```
### What
- Fixes an issue where `after()` in an edge page would not run if the
request was cancelled/aborted
- Unskips the `runs callbacks if redirect() was called` test which was
disabled to not block other things

### Background

This was initially hit in #75882, during which the `runs callbacks if
redirect() was called` test started failing when using experimental
react + turbo in dev mode. Turns out that this happenws because
something got slower and we weren't finishing the redirect response in
time, i.e. before the browser disconnected and started loading the page
it got redirected to.

It's relevant that the response didn't finish streaming, because in
`edge`, we use that as the trigger to start running `after()` callbacks.
In particular, we instrument the response stream using
`trackStreamConsumed`. The problem was that this function didn't handle
the stream being cancelled, which is what happens when a request is
aborted mid-streaming, so `after()` never ended up executing.

This PR fixes that and adds some tests for cancellation and interrupted
streaming.
### What?
When doing an On Demand revalidation (with `res.revalidate` or using
`x-prerender-revalidate` header ), `use cache` entry will never get
revalidated

### Why?
It should behave the same as the fetch cache or `unstable_cache`

### How?

We force revalidation of `use cache` entry when doing an on demand
revalidation

---------

Co-authored-by: Hendrik Liebau <[email protected]>
Default cache handlers should be allowed and not trigger a build error.
## What?

For edge we generate everything in the `middleware-manifest.json`
(should be renamed edge-manifest tbh, but it's not for legacy reasons).
This change to the tests makes sure the right thing is checked in the
directory output, that `.html` and `.rsc` are written.

<!-- 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:

## For Contributors

### Improving Documentation

- 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

### Adding or Updating Examples

- 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

### Fixing a bug

- 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

### Adding a feature

- 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


## For Maintainers

- 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

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
## What?

Ensures the updated matcher output works. Both outputs are functionally
correct.

<!-- 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:

## For Contributors

### Improving Documentation

- 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

### Adding or Updating Examples

- 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

### Fixing a bug

- 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

### Adding a feature

- 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


## For Maintainers

- 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

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
### Why?

Since the dev indicator is visible by default, there could be a case where a user might want to disable it.
However, the indicator needs to be brought back if there is an error since it's tied to the error overlay.

### What?

Added an option `devIndicators: false` to disable the dev indicator.

### Success Criteria

- [x] Does it hide the indicator when there is no error?
- [x] Does it show the indicator when there is an error?
- [x] Does it show the error overlay when there is an error?

Closes NDX-840
…or scroll position testing (#76105)

### Why?

There were explicit `paddingBottom: 60` set to fixtures due to the dev
indicator blocking the scroll position. Since an option to disable it
was added at #76079, this PR
replaced them with `devIndicators: false`.

x-ref:
#76077 (comment)
- Every `EcmascriptChunkItem` already had a `chunking_context()` getter via the `ChunkItem` supertrait.
- Produce less turbo tasks for `chunk_item.id()`
- In the future, we really want to move `chunking_context.chunk_item_id()` to the module graph, (or split it out and instead pass a `Vc<ModuleIdStrategy>`). That is however a refactoring we don't need to do right now.

This showed up in the traces, but overall it doesn't seem to have an effect on perf.
Before:
![Bildschirmfoto 2025-02-17 um 09 34 05](https://github.com/user-attachments/assets/99b4816e-9056-418c-8d69-4d6535b9d296)

After:
![Bildschirmfoto 2025-02-17 um 13 43 04](https://github.com/user-attachments/assets/e4409ef6-831e-464f-900c-ec071b916a88)
This PR is a follow-up to #76100 that enables on-demand revalidation via
an API route in development mode. This is accomplished by implementing
three changes:
1. We need to forward the user cookies, including the
`__next_hmr_refresh_hash__` value, which is required to generate the
same cache key _during_ the revalidation as _before_ and, more
importantly, _after_ the revalidation. Otherwise the revalidated cache
entries will use a different cache key (without the refresh hash), and
on subsequent page reload, the stale cached data would still be shown
(using the cache key with refresh hash).
2. When checking if a `revalidate()` call succeeded, we allow `200`
responses in general, and only check the `'x-nextjs-cache'` header for
`404` response. This matches the historic intent of the feature.
([x-ref-1](https://github.com/vercel/next.js/pull/36108/files#diff-8d464ed8b3d6ed08deabeaa05180900c38f8943d75368798861d1734103512fcR338-R342),
[x-ref-2](https://github.com/vercel/next.js/pull/34826/files#diff-8d464ed8b3d6ed08deabeaa05180900c38f8943d75368798861d1734103512fcR318-R324)).
3. The `isOnDemandRevalidate` status is now also set for non-`isSSG`
pages, based on the `'x-prerender-revalidate'` header. This matches the
logic in the incremental cache handler, which enables cache revalidation
in dev mode when using `unstable_cache`.
## What?

This test is already passing with Turbopack, updating the manifest.

<!-- 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:

## For Contributors

### Improving Documentation

- 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

### Adding or Updating Examples

- 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

### Fixing a bug

- 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

### Adding a feature

- 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


## For Maintainers

- 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

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
## What?

Improves the check for browser sourcemaps by reading all sourcemap files
from the `.next/static` folder instead of trying to locate a specific
value. The sensitive value that is being checked should not exist in any
of the sourcemap files so it's safer to check them all. This also
ensures that if for example the underlying bundling heuristics change
the check will still fail. In this case it was failing on the path with
Turbopack, instead of on the value. This ensures it checks the value.

<!-- 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:

## For Contributors

### Improving Documentation

- 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

### Adding or Updating Examples

- 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

### Fixing a bug

- 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

### Adding a feature

- 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


## For Maintainers

- 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

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->

---------

Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
### What?

ChangeLog: swc-project/swc@[email protected][email protected]

### Why?

To keep in sync

### How?
### What?

Simplify `minify()` of turbopack. `swc::Compiler` is not required for the minification, considering that we are not using the minification API of it.

### Why?

It has some tiny overheads, and it disturbs future refactoring for source maps.
#76113)

### Why?

The overlay seemed too low when the content was long since it had both
`padding` and `top` values. Adjust to have only the `top` and preserve
the `padding` value.

### Before


https://github.com/user-attachments/assets/e2172a7b-1275-4647-88e2-7b91fc4c8d98

### After


https://github.com/user-attachments/assets/182cfa7b-d532-4bb7-aa0c-69911720b370

Closes NDX-845
Tested by commenting out the turbopack upload bits (since I don't want to risk messing up that dataset) and running:

```
TURBOYET_KV_REST_API_TOKEN="..." TURBOYET_KV_REST_API_URL="..." node .github/actions/upload-turboyet-data/dist/index.js
```

I got the API token from the areweturboyet deployment in the vercel dashboard.

I think it's fine and easiest to just use the same KV database for both bundlers with different key prefixes.
## Why?

Adding an `Error Overlay` area (will add label as well) so we can start tracking issues with the new Error Overlay.
@pull pull bot merged commit c43d73d into MLH-Fellowship:canary Feb 18, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.