Skip to content
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

[pull] canary from vercel:canary #3

Merged
merged 5,150 commits into from
Jan 7, 2025
Merged

[pull] canary from vercel:canary #3

merged 5,150 commits into from
Jan 7, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Jul 4, 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 added the ⤵️ pull label Jul 4, 2024
gaojude and others added 29 commits December 11, 2024 13:13
Because the next-error-code-swc-plugin crate uses the wasm32-wasip1
target, including it in the workspace causes cargo check to fail, which
in turn causes the main build to fail. To work around this, I'm removing
the crate from the workspace.
This pull request adds a more prominent error message to the CI build
failure message when a new error message is added through `new
Error(...)` but `pnpm build` has not been run locally to update
`errors.json`.


**Example**

![CleanShot 2024-12-11 at 13 38
52@2x](https://github.com/user-attachments/assets/6ab89823-4dc9-4bf2-a8a5-eae9a53e1fd0)
…c`s and `OperationVc`s (#73764)

This is a follow-up to #73714

**What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html

The core change here is this bit in `turbopack/crates/turbo-tasks/src/vc/local.rs`:

```diff
- unsafe impl<T: ?Sized + NonLocalValue> NonLocalValue for OperationVc<T> {}
- unsafe impl<T: ?Sized + NonLocalValue> NonLocalValue for ResolvedVc<T> {}
+ unsafe impl<T: ?Sized> NonLocalValue for OperationVc<T> {}
+ unsafe impl<T: ?Sized> NonLocalValue for ResolvedVc<T> {}
```

These new implementations are intentionally incorrect, as these values `T` could contain references to local `Vc` values. We must also check that `T: NonLocalValue`. However, we're temporarily ignoring that problem, as:

- We don't *currently* depend on `NonLocalValue` for safety (local tasks aren't enabled).
- We intend to make all `VcValueType`s implement `NonLocalValue`, so implementing this for all values is approximating that future state.
- Adding a `T: NonLocalValue` bound introduces a lot of noise that isn't directly actionable for types that include a `ResolvedVc` or `OperationVc` that is not *yet* a `NonLocalValue`.

This PR also adds the `NonLocalValue` to types explicitly deriving `TraceRawVcs`, for types that couldn't before, by using the new weaker bounds on the `NonLocalValue` impls.
Co-authored-by: Delba de Oliveira <[email protected]>
Co-authored-by: Lee Robinson <[email protected]>
Follow-up to #73715. Since PPR should always result in a cache hit for a
prefetch (even in the worst case, there's a fallback cache entry), the
only reason a route tree prefetch would not be found in the per-segment
cache is because PPR is disabled.

So we should just fallthrough to the old prefetching flow whenever PPR
is disabled.

But the client still needs some way to tell whether the response was
served from the per-segment cache or by the old implementation.

So I added an explicit response header to every per-segment prefetch. If
the header is missing, the client can infer that the route does not
support PPR.
if we're on windows and the path happens to be absolute, not escaping
the path can lead to generating invalid code. for example, with a path
like `C:\Users\notgood\...`, the `\n` **will be interpreted as a
newline** when the module is parsed, and thus blow up multiple things
downstream
LayoutRouter has changed significantly since it was originally written
and the structure has become harder to follow. One thing I always find
confusing whenever I'm reading this code is that some of the values
correspond the the *parent* segment, while others correspond to the
*current* segment. So this moves the code around a bit and updates the
names so it's clearer which parts belong to which segments.

While working on this, I noticed a funny thing about how loading
boundaries work that was made more obvious by the revised naming. I've
left a TODO comment to follow up on whether this was intentional.
Based on:
- #73540

---

Currently if you navigate to a partially static route, the server will
always start rendering at the first segment that's not present on the
previous page. However, it should really start rendering at the first
*dynamic* segment — if the client has already prefetched a segment, and
it's fully static, there's no reason to render it again during the
dynamic server render.

We can do this by sending a more specific Next-Router-State-Tree request
header. Rather than send a tree that represents the previous route, we
sent the tree of the target route, but with a `refetch` marker added to
the first dynamic segment. (Without the refetch marker, the server would
send back an empty response.) This is determined by diffing against both
the previous route *and* the prefetch cache.

For now, this only works up to the first dynamic segment inside the new
subtree; once the server starts rendering along a path, it renders
everything else along that path. We could improve this in the future to
also omit static segments that appear inside a dynamic layout, though
this would likely require a change to the Next-Router-State-Tree
protocol.
When the client Segment Cache attempts to prefetch a route tree, and it
the route does not have PPR enabled, the server falls through to the old
implementation, which sends back a FlightRouterState.

This is fine, since the client can use the FlightRouterState to recreate
the non-PPR behavior.

However, when loading.tsx is present in the route, the server will not
just send back the FlightRouterState, but also render the page up to the
first loading boundary. This is not what we want in the Segment Cache
implementation — we want the route tree only, so we can determine which
parts the client already has before sending a second request for the
rest.

So this PR disables the loading.tsx mechanism when prefetching the route
tree, by checking the Next-Router-Segment-Prefetch header.
Based on:

- #73826 

---

This removes the `segmentPath` prop from the LayoutRouter payload. This
can be derived on the client from the FlightRouterState instead.
## Summary

Both `app/actions.ts` and `app/action.js` aren't JSX in [error
handling](https://nextjs.org/docs/app/building-your-application/routing/error-handling)
docs.
`app/api/route.ts` and `app/api/route.js` aren't also JSX in
[after](https://nextjs.org/docs/app/api-reference/functions/after) docs.

### Improving Documentation

- [x] Run `pnpm prettier-fix` to fix formatting issues before opening
the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution
follows the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

Co-authored-by: JJ Kasper <[email protected]>
if this `fetch` fails it's kinda annoying to find, because it just gets
printed as
```
│ [17:05:40] precompile failed because fetch failed     
```
this change should at least make it easier to find the cause by
searching for the error message:
```
│ [17:20:27] precompile failed because Failed to fetch AMP validator
```
## Problem

When generating route regular expressions for data routes, some code
paths appear to not escape the `.` in `.json`. This causes routing to be
slightly slower, prevents some optimizations related to static
postfixes, and potentially allows for unintended request paths to be
accepted as value.

## Solution

After much tracing and digging, I found a code path writing regular
expressions directly without escaping. In this case the solution is to
escape the `.` using `\\.` when generating static data routes.

A simple next app was made to exercise this path with a route
`pages/server-time.tsx` that contains a simple `getServerSideProps`.

```tsx
import type { InferGetServerSidePropsType, GetServerSideProps } from 'next'
 
type TimeDate = {
  timestamp: number
}
 
export const getServerSideProps = (async () => {
  return { props: { timestamp: Date.now() } }
}) satisfies GetServerSideProps<TimeDate>
 
export default function Page({
  timestamp,
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  return (
    <main>
      <p>{new Date(timestamp).toUTCString()}</p>
    </main>
  )
}
```

Before the change, the generated route regexp was
`"^/_next/data/[build_id]/server-time.json$"`, but after then change it
becomes `"^/_next/data/[build_id]/server-time\\.json$"`

The related tests were updated to expect properly escaped `\\.json$`
endings to the regexps.
…72095)

# What

This PR fixes a bug when using next@15, next/dynamic and assetPrefix
config in App Router.

# Why

The current behavior loads the CSS with only the pathname and so, it
results with a 404.


# How

The new behavior uses the full url of the asset.

Fixes #72470

<!-- 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: Tobias Koppers <[email protected]>
Co-authored-by: JJ Kasper <[email protected]>
…_trait macros (#73766)

**Recommendation:** Review [the individual commits](https://github.com/vercel/next.js/pull/73766/commits) in order!

**What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html

1. Switches the default behavior of `#[turbo_tasks::value]` and `#[turbo_tasks::value_trait]` to derive `NonLocalValue`, with an opt-out (previously, this was just opt-in).
2. *(Automated, codemod)* Remove pre-existing opt-ins to `NonLocalValue` (as this is now the default behavior)
3. Manually add `NonLocalValue` to a couple more common types.
4. *(Automated, codemod)* Add `local` annotations to structs and traits with errors.

Normally I'd split this sort of thing up across a few PRs, but steps 1, 2, and 4 must be atomic (must land together).

---

Removing pre-existing opt-ins was done with a couple regexes:

```
fastmod --accept-all '#\[turbo_tasks::value(?<trait>_trait)?\(((?<prefix>.*), )?non_local(?<suffix>.*)\)\]' '#[turbo_tasks::value${trait}(${prefix}${suffix})]'
fastmod --accept-all '#\[turbo_tasks::value(?<trait>_trait)?\(\)\]' '#[turbo_tasks::value${trait}]'
```

Adding `local` annotations to structs/enums and traits was done with this kludge (partially sourced from chatgpt):

```
cargo check --message-format=json 2>/dev/null | jq -r '. | select(.message.children != null) | .message.children[] | select(.spans != null) | .spans[] | select(.expansion.macro_decl_name == "#[derive(turbo_tasks::NonLocalValue)]") | .file_name + " " + (.line_start|tostring) + " " + (.line_end|tostring)' | sort -u | xargs -I{} bash -c 'args=($1); file="${args[0]}"; line="${args[1]}"; echo "Processing: $file $line" >&2; sed -i "${line}s/#\[turbo_tasks::value(\([^)]*\))\]/#[turbo_tasks::value(\1, local)]/; ${line}s/#\[turbo_tasks::value\]/#[turbo_tasks::value(local)]/" "$file"' -- {} && \
cargo check --message-format=json 2>/dev/null | jq -r '. | select(.message.children != null) | .message.children[] | select(.spans != null) | .spans[] | select(.expansion.macro_decl_name == "#[turbo_tasks::value_trait]") | .file_name + " " + (.line_start|tostring) + " " + (.line_end|tostring)' | sort -u | xargs -I{} bash -c 'args=($1); file="${args[0]}"; line="${args[1]}"; echo "Processing: $file $line" >&2; sed -i "${line}s/#\[turbo_tasks::value_trait(\([^)]*\))\]/#[turbo_tasks::value_trait(\1, local)]/; ${line}s/#\[turbo_tasks::value_trait\]/#[turbo_tasks::value_trait(local)]/" "$file"' -- {}
```

Which I just ran a bunch of times until `cargo check` no longer generated any errors.
I forgot to exclude `.test.` files from the next error code plugin. This
caused a bunch of errors codes from test files to pollute `errors.json`.
I added a filter to exclude the test files and then reset `errors.json`.
… `T: NonLocalValue` (#73770)

Title says it all. This lets us implement `NonLocalValue` on more structs.

**What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html
devjiwonchoi and others added 29 commits January 7, 2025 02:50
This PR separated the error message component.

### Light

![CleanShot 2025-01-06 at 18 20 31](https://github.com/user-attachments/assets/3379bf69-743c-4431-8e03-e051be7f30e2)

### Dark

![CleanShot 2025-01-06 at 18 21 47](https://github.com/user-attachments/assets/d70309c5-df35-4f32-82a6-e9776976c632)

Closes NDX-608
This PR added the error type label.

### Light

![CleanShot 2025-01-06 at 19 08 56](https://github.com/user-attachments/assets/1e85d19e-b989-4e1a-914d-567abfb309d2)

### Dark

![CleanShot 2025-01-06 at 19 08 50](https://github.com/user-attachments/assets/c5d2e6a6-f43e-4134-b1b7-0dc13eb83cd4)

Closes NDX-607
We're adding a new feature to the error overlay that allows developers
to rate the current error message. Developers can rate the error message
by clicking on the thumb up or down icon in the error overlay footer.

This pull request adds the click handler for the error rating buttons.
When the buttons are clicked, the click handler calls a previously
implemented internal API endpoint. The endpoint is connected to the
usual Next.js Telemetry.

To test the UI, run `pnpm storybook` and go to
http://localhost:6006/?path=/story/erroroverlaylayout--default.



https://github.com/user-attachments/assets/6daf6e64-e8bb-4e5e-b282-082086f1e529
### Improving Documentation

I was just upgrading from Next.js v13 to v14 following this guide:

https://nextjs.org/docs/app/building-your-application/upgrading/version-14

npm installation throws the below error:

```sh
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: [email protected]
npm error Found: [email protected]
npm error node_modules/react
npm error   react@"19.0.0" from the root project
npm error
npm error Could not resolve dependency:
npm error peer react@"^18.2.0" from [email protected]
npm error node_modules/next
npm error   next@"14.2.21" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.
```

The react version for Next.js v14 should be pinned to react@18.
Improved a11y (aria-live, aria-label) and simplified loading/error state
to prevent double firing when feedback buttons get clicked multiple
times while loading.
## What?
Added accessibility improvements to the error overlay voting buttons by making their icons properly hidden from screen readers.

## Why?
To enhance accessibility for users relying on screen readers by preventing redundant icon announcements while maintaining the clear button labels "Mark as helpful" and "Mark as not helpful".

## How?
- Added `ComponentProps<'svg'>` type to ThumbsUp and ThumbsDown components to allow passing SVG attributes
- Spread props to SVG elements to enable aria attributes
- Added test coverage to ensure icons have `aria-hidden="true"`
This auto-generated PR updates font data with latest available
## Why?

- Update React in reproduction example templates to stable v19
- Switch `.ts` for `next.config`
- Fixes #74422
## Why?

Updating from `STALE_TOKEN` to `RELEASE_BOT_TOKEN` because `STALE_TOKEN` has expired.
Fixes #74062 (`jotai` ran into this error [when they added `"type":
"commonjs"` to their
package.json](pmndrs/jotai#2579 (reply in thread)))

> this is a bug in the transform we do when a `'use client'` directive
is encountered. I think what's happening is that we're creating a
virtual file that uses ESM import/export syntax, but it's called
proxy.js (not proxy.mjs), so the `"type": "commonjs" `makes turbopack
"correctly" upset at the ESM syntax.
#74062 (comment)

The (slightly kludgy) solution is to use `proxy.mjs` or `proxy.cjs` to
force the module format, bypassing the issue where `proxy.js` changes
meaning depending on `package.json#type`.
### What?

updates shadow-rs dependency, which fixes the build.rs caching problem: https://github.com/baoyachi/shadow-rs/pull/195/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R40

Also prints the git version during the build
This PR added style for Toolbar buttons, and moved files to `Errors/error-overlay-toolbar`.

Will follow up with TBD:

- Replace the Node.js button with the "Debugging" Icon
- Add Docs Button?

### Light

![CleanShot 2025-01-07 at 01 12 52](https://github.com/user-attachments/assets/a26ad870-d938-4b24-a8e7-2409e65026d1)

### Dark

![CleanShot 2025-01-07 at 01 12 25](https://github.com/user-attachments/assets/0abe5d67-677b-4002-bf43-6d7a26dee602)

Closes NDX-601
Closes NDX-602
this comment is a useful explanation, but was accidentally lost in
#52846, when a bunch of loader stuff was unified between webpack and
turbopack

see:
https://github.com/vercel/next.js/pull/52846/files#diff-173d1bc6424869c0d3c43f8fba124186427d03e5bd056587f141886a0075b1d3L699-L700
## What?

Skips the websocket ping for Turbopack. Currently the ping is only used
by the webpack integration to keep track of "active" entrypoints that
are still being viewed. Entrypoints that are no longer viewed will be
disposed from the webpack compiler.

With Turbopack this mechanism is not used and it keeps the entrypoints
around. Removing the ping makes the websocket events easier to monitor
and read while debugging.


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

-->
This ensures we don't lose tags added to a page before `notFound()` is
called as otherwise a fetch on the page that has been revalidated won't
be able to be applied correctly if dropped from a `notFound()` call.
This was broken recently in the refactors of handling rendering in
app-render as it worked correctly in `v14`.

x-ref: [slack
thread](https://vercel.slack.com/archives/C04V3E1UYNQ/p1736200963684869)

Closes https://linear.app/vercel/issue/ENET-1381
Closes https://linear.app/vercel/issue/NEXT-3946
Closes #73973
Closes #66540
While many use case-specific graphs belong in Next.js, this primitive
should be kept in Turbopack as it will be used for other core usecases
like chunking.

Test Plan: CI
This PR allows `.stories.tsx` files to be viewed as nested when they share the same filename with `.ts` and `.tsx`, similar to the `.test.` files.

https://github.com/user-attachments/assets/8e280369-984d-4d33-b91a-392b3c18b5d9
Prerender errors triggered during development should be rethrown by the
`unstable_rethrow` api.

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

-->
…App router (#74440)

This PR updates the with-react-jss example to use the App Router. Here
are the changes that have been made:

- Renamed the `pages` folder to the `app` folder.
- Converted the `index.tsx `to `page.tsx` file as part of the App
Router.
- Created `layout.tsx` in app directory, merging functionality from both
`_app.tsx` and `_document.tsx`:
  - Wraps content with `StyledComponentsRegistry`
- Created `app/registry.tsx` for JSS setup:
    - Moved JSS Provider and SheetsRegistry from _document.tsx
    - Moved style cleanup logic from _app.tsx
    - Handles server-side style generation
- Updated the package.json file.

The following actions were performed as part of this PR:

- Ran `pnpm prettier-check` with no issues found.
- Executed the `pnpm check-examples` script.

CC: @samcx

---------

Co-authored-by: samcx <[email protected]>
## Why?

It turns out the `react/self-closing-comp` rule is not necessary to cover for JSX tags that are not properly closed.
@pull pull bot merged commit 9b79c11 into code:canary Jan 7, 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.