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

Fix: missing equal sign #1

Merged
merged 2,909 commits into from
Aug 7, 2023
Merged

Fix: missing equal sign #1

merged 2,909 commits into from
Aug 7, 2023

Conversation

shenlu89
Copy link
Owner

@shenlu89 shenlu89 commented Aug 7, 2023

ijjk and others added 30 commits July 18, 2023 18:12
Renames the webpack layers to be more semantical:

```
server compiler:
server layer → RSC layer
client layer → SSR layer
shared layer → shared layer

client compiler:
appClient layer → app browser layer
```
…52832)

### What?

refactoring see vercel/turbo#5557

### Turbopack Changes

* vercel/turbo#5506 <!-- Leah -
feat(turbopack-ecmascript): implement acyclic SCC graph for ESM imports
-->
* vercel/turbo#5557 <!-- Tobias Koppers - Ensure
output assets reference only output assets -->
This pull request replaces `readdir` with `opendir` and simplifies the
implementation.

Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What?

Uses `COPY --link` instructions in Docker examples.

### Why?

This significantly [accelerates Docker builds and improves caching](https://www.howtogeek.com/devops/how-to-accelerate-docker-builds-and-optimize-caching-with-copy-link/).

This instruction is supported for more than 1 year and is now supported by almost all modern Docker installations.
We use it successfully for a while in [the API Platform distribution](https://github.com/api-platform/api-platform/blob/main/pwa/Dockerfile), which includes Next.js and is derived from these examples.

### How?

By updating the existing examples.
This reverts commit 85bd7cc.
Added clarification that runtime edge can be defined on Layout level too.

Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
As we're using nodejs with latest version of 18.x on CI, there's a new behavior change of `url.fileURLToPath` that didn't join the paths as expected

locally with node 16.x or 18.16
```
/private/var/folders/mh/y8kwzkls6v3_w3_k6q384cw80000gn/T/next-install-b033b516612809c6fb0a0de77c6e50f7d7f8af34dfd3d01812b99345352dc992/node_modules/.pnpm/file+..+next-repo-7e52b07043e986127273a2d951e5c412b0dd45fb24eb34001bd372e2afff79db+packages+n_vyqu6i4c4i3efp5pqsaeaoe5s4/node_modules/next/dist/compiled/@vercel/og/noto-sans-v27-latin-regular.ttf
```

in the actions runner with node 18.17 it's
```
/tmp/next-install-8efaa47c1546bed07990d8f130decceb6536e1a36146e7885cb68e3c3dea21f7/node_modules/.pnpm/file+..+next-repo-9679355e05341947e7aa0b42c994e3ac_krcuriy4thl7zawouf7sswlrgy/node_modules/next/dist/compiled/@vercel/og/index.node.js/../noto-sans-v27-latin-regular.ttf
```

You can see that `index.node.js` is still present in the path as a folder which is unexpected
```
index.node.js/../
```

x-ref: https://github.com/vercel/next.js/actions/runs/5600417148/jobs/10242827739?pr=52790
### What?

* adds `Project.update` to update project options
* fix manifest paths to be under `server`
* pass `env` into project
* handle and expose issues in all methods
* expose server paths in WrittenEndpoint
…ta (vercel#52902)

Fixes vercel#52853

Lacking 'color' attribute in IconDescriptor  Metadata

```diff
export type IconDescriptor = {
  url: string | URL
  type?: string
  sizes?: string
+ color?: string          // added the color attribute 
  /** defaults to rel="icon" unless superseded by Icons map */
  rel?: string
  media?: string
  /**
   * @see https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority
   */
  fetchPriority?: 'high' | 'low' | 'auto'
}
```


https://github.com/vercel/next.js/blob/v13.4.11-canary.0/packages/next/src/lib/metadata/types/metadata-types.ts#L99
Fixes a bug where the edge runtime didn't support `basePath` with Custom App Routes.

- Fixes vercel#49661
### What?
- Visiting a page in the app router without a proper component export doesn't show the dev overlay, but logs errors to the console
- When it does show the error overlay (e.g. during an HMR event), the error message was sharing the module code itself rather than the component path, making it hard to debug

### Why?
`createComponentTree` can throw these errors before the AppRouter tree is mounted, leaving the errors uncaught by the dev overlay.

### How?
This wraps the server root in the `ReactDevOverlay` when in dev mode with a minimal "HMR" for when the server component is edited (to reload the page).

Closes NEXT-308
…l#52915)

We were preventing smooth scrolling to avoid jarring UX when `scroll-behavior: smooth` was set and the user navigates to another route ([PR](vercel#40642) and [related comment](vercel#51721 (comment))). 

This updates both pages & app router to restore smooth scroll functionality if the only the route hash changes.

Fixes vercel#51721
Closes NEXT-1406
### What?

adds edge pages, apis, app pages and app routes to next.rs api

### Why?

### How?
### What?

Adds a GitHub Action that automatically marks unhelpful comments as "off-topic".

You can test it by adding off-topic comments to this issue: balazsorban44#21

https://github.com/balazsorban44/next.js/blob/17e3ec30689a2323161260c9b03bb7f51ed008f9/.github/actions/minus-one/src/index.mjs#L6

### Why?

A common problem is when an issue thread receives "+1" comments, it usually encourages others to do the same. This makes the thread harder and harder for maintainers to read, without adding value to the discussion.

### How?

When an issue receives a comment, we compare it to a list that we determine as off-topic. If it matches, we hide the comment.

See: https://docs.github.com/en/graphql/reference/mutations#minimizecomment
Closes vercel#52898

LangCode Missing zh-Hans and zh-Hant

| 'yo-NG'
  | 'zh-CN'
  | 'zh-Hans'   //added
  | 'zh-Hant'        //added
  | 'zh-HK'
  | 'zh-MO'
  | 'zh-SG'
  | 'zh-TW'
  | 'zu-ZA'


https://github.com/vercel/next.js/blob/f5272acbe5628164257ef8e584c8a469a4af5cb8/packages/next/src/lib/metadata/types/alternative-urls-types.ts#L419


Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
…ng Named Imports" (vercel#52932)

The correct filename is seen on PagesOnly. But on AppOnly, the filename is not correct. It should be "hello" instead of "ClientComponent".

line to change:
from:
import('../components/ClientComponent').then((mod) => mod.Hello)

to:
import('../components/hello').then((mod) => mod.Hello)


line to change:
from:
import('../components/ClientComponent').then((mod) => mod.Hello)

to:
import('../components/hello').then((mod) => mod.Hello)
### What?

Stop `with-supabase` template from throwing errors on build

### Why?

Dynamic Routes now fail the build, rather than console.logging an error

### How?

Export the following from any routes that use the `cookies` function

```
export const dynamic = "force-dynamic";
```

Install `encoding` as a dev dependency until this is fixed downstream
We have the logic to group the client compiler's entry names to make sure we generate one single manifest file for the page. This is complicated and requires a special step to "group" the entry names because a page can depend on a bunch of files from everywhere.

And currently, the normalization of "entryName → groupName" doesn't cover interception routes' conventions (`(.)`, `(..)` and `(...)`). This PR fixes that.

Closes vercel#52862, closes vercel#52681, closes vercel#52958.
### What and why?

The word "publicly" should be spelled consistently across the documentation. It is spelled currently as "publically" in a few places.

### How?

Fixed the spelling!
sokra and others added 28 commits August 4, 2023 21:14
This PR updates cache revalidation snippets in the docs. It seems that `res` should not be there since you can't find it anywhere in the snippet so I suppose that the intent was to use `NextResponse` instead. Another thing is that now we're checking the existence of the params so typescript doesn't get mad at us. And last I changed the methods to `POST` since AFAIK webhooks normally use the `POST` method.

Please let me know if there's anything left to do on my side.

Have a great day!

Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
### What?
Fix example `with-supabase` https://github.com/vercel/next.js/tree/canary/examples/with-supabase signup button

### Why?
Signup button text color is not the right one so the developer is not able to see the text.

### How?
Updated the style using tailwind as it is what we are using in the example.

Before:
![image](https://github.com/vercel/next.js/assets/1652286/269c3be1-70ee-4b92-9161-4d1c35cbd01c)

After (Fixed):
![image](https://github.com/vercel/next.js/assets/1652286/3aa6af87-7958-470d-bf05-d1187963e792)
This removes the `basePath` from the output of `usePathname`. Previously this always resulted in hydration errors, this now strips the `basePath` when it's found/configured.

Now when you configure `basePath`, you don't have to factor it into your application logic and can instead rely on the values always returning the pathname without it.

Fixes vercel#46562
This ensures `revalidateTag()` doesn't cause an async/background revalidation unexpectedly and instead does a blocking revalidate so fresh data is shown right away when a path is using ISR. 

Test deployment with patch can be seen here: https://next-revalidation-test-47rqf8q5s-vtest314-ijjk-testing.vercel.app/

Fixes: vercel#53187
## Vendoring

Updates all module resolvers (node, webpack, nft for entrypoints, and nft for next-server) to consider whether vendored packages are suitable for a given resolve request and resolves them in an import semantics preserving way.

### Problem

Prior to the proposed change, vendoring has been accomplished but aliasing module requests from one specifier to a different specifier. For instance if we are using the built-in react packages for a build/runtime we might replace `require('react')` with `require('next/dist/compiled/react')`.

However this aliasing introduces a subtle bug. The React package has an export map that considers the condition `react-server` and when you require/import `'react'` the conditions should be considered and the underlying implementation of react may differ from one environment to another. In particular if you are resolving with the `react-server` condition you will be resolving the `react.shared-subset.js` implementation of React. This aliasing however breaks these semantics because it turns a bare specifier resolution of `react` with path `'.'` into a resolution with bare specifier `next` with path `'/dist/compiled/react'`. Module resolvers consider export maps of the package being imported from but in the case of `next` there is no consideration for the condition `react-server` and this resolution ends up pulling in the `index.js` implementation inside the React package by doing a simple path resolution to that package folder.

To work around this bug there is a prevalence of encoding the "right" resolution into the import itself. We for instance directly alias `react` to `next/dist/compiled/react/react.shared-subset.js` in certain cases. Other times we directly specify the runtime variant for instance `react-server-dom-webpack/server.edge` rather than `react-server-dom-wegbpack/server`, bypassing the export map altogether by selecting the runtime specific variant. However some code is meant to run in more than one runtime, for instance anything that is part of the client bundle which executes on the server during SSR and in the browser. There are workaround like using `require` conditionally or `import(...)` dynamically but these all have consequences for bundling and treeshaking and they still require careful consideration of the environment you are running in and which variant needs to load.

The result is that there is a large amount of manual pinning of aliases and additional complexity in the code and an inability to trust the package to specify the right resolution potentially causing conflicts in future versions as packages are updated.

It should be noted that aliasing is not in and of itself problematic when we are trying to implement a sort of lightweight forking based on build or runtime conditions. We have good examples of this for instance with the `next/head` package which within App Router should export a noop function. The problem is when we are trying to vendor an entire package and have the package behave semantically the same as if you had installed it yourself via node_modules

### Solution

The fix is seemingly straight forward. We need to stop aliasing these module specifiers and instead customize the resolution process to resolve from a location that will contain the desired vendored packages. We can then start simplifying our imports to use top level package resources and generally and let import conditions control the process of providing the right variant in the right context.

It should be said that vendoring is conditional. Currently we only vendor react pacakges for App Router runtimes. The implementation needs to be able to conditionally determine where a package resolves based on whether we're in an App Router context vs a Page Router one.

Additionally the implementation needs to support alternate packages such as supporting the experimental channel for React when using features that require this version.

### Implementation

The first step is to put the vendored packages inside a node_modules folder. This is essential to the correct resolving of packages by most tools that implement module resolution. For packages that are meant to be vendored, meaning whole package substitution we move the from `next/(src|dist)/compiled/...` to `next/(src|dist)/vendored/node_modules`. The purpose of this move is to clarify that vendored packages operate with a different implementation. This initial PR moves the react dependencies for App Router and `client-only` and `server-only` packages into this folder. In the future we can decide which other precompiled dependencies are best implemented as vendored packages and move them over.

It should be noted that because of our use of `JestWorker` we can get warnings for duplicate package names so we modify the vendored pacakges for react adding either `-vendored` or `-experimental-vendored` depending on which release channel the package came from. While this will require us to alter the request string for a module specifier it will still be treating the react package as the bare specifier and thus use the export map as required.

#### module resolvers
The next thing we need to do is have all systems that do module resolution implement an custom module resolution step. There are five different resolvers that need to be considered

##### node runtime
Updated the require-hook to resolve from the vendored directory without rewriting the request string to alter which package is identified in the bare specifier. For react packages we only do this vendoring if the `process.env.__NEXT_PRIVATE_PREBUNDLED_REACT` envvar is set indicating the runtime is server App Router builds. If we need a single node runtime to be able to conditionally resolve to both vendored and non vendored versions we will need to combine this with aliasing and encode whether the request is for the vendored version in the request string. Our current architecture does not require this though so we will just rely on the envvar for now

##### webpack runtime
Removed all aliases configured for react packages. Rely on the node-runtime to properly alias external react dependencies. Add a resolver plugin `NextAppResolverPlugin` to preempt perform resolution from the context of the vendored directory when encountering a vendored eligible package.

##### turbopack runtime
updated the aliasing rules for react packages to resolve from the vendored directory when in an App Router context. This implementation is all essentially config b/c the capability of doing the resolve from any position (i.e. the vendored directory) already exists

##### nft entrypoints runtime
track chunks to trace for App Router separate from Pages Router. For the trace for App Router chunks use a custom resolve hook in nft which performs the resolution from the vendored directory when appropriate.

##### nft next-server runtime
The current implementation for next-server traces both node_modules and vendored version of packages so all versions are included. This is necessary because the next server can run in either context (App vs Page router) and may depend on any possible variants. We could in theory make two traces rather than a combined one but this will require additional downstream changes so for now it is the most conservative thing to do and is correct

Once we have the correct resolution semantics for all resolvers we can start to remove instances targeting our precompiled instances for instance making `import ... from "next/dist/compiled/react-server-dom-webpack/client"` and replacing with `import ... from "react-server-dom-webpack/client"`

We can also stop requiring runtime specific variants like `import ... from "react-server-dom-webpack/client.edge"` replacing it with the generic export `"react-server-dom-webpack/client"`

There are still two special case aliases related to react
1. In profiling mode (browser only) we rewrite `react-dom` to `react-dom/profiling` and `scheduler/tracing` to `scheduler/tracing-profiling`. This can be moved to using export maps and conditions once react publishses updates that implement this on the package side.
2. When resolving `react-dom` on the server we rewrite this to `react-dom/server-rendering-stub`. This is to avoid loading the entire react-dom client bundle on the server when most of it goes unused. In the next major react will update this top level export to only contain the parts that are usable in any runtime and this alias can be dropped entirely

There are two non-react packages currently be vendored that I have maintained but think we ought to discuss the validity of vendoring. The `client-only` and `server-only` packages are vendored so you can use them without having to remember to install them into your project. This is convenient but does perhaps become surprising if you don't realize what is happening. We should consider not doing this but we can make that decision in another discussion/PR.

#### Webpack Layers
One of the things our webpack config implements for App Router is layers which allow us to have separate instances of packages for the server components graph and the client (ssr) graph. The way we were managing layer selection was a but arbitrary so in addition to the other webpack changes the way you cause a file to always end up in a specific layer is to end it with `.serverlayer`, `.clientlayer` or `.sharedlayer`. These act as layer portals so something in the server layer can import `foo.clientlayer` and that module will in fact be bundled in the client layer.

#### Packaging Changes
Most package managers are fine with this resolution redirect however yarn berry (yarn 2+ with PnP) will not resolve packages that are not defined in a package.json as a dependency. This was not a problem with the prior strategy because it was never resolving these vendored packages it was always resolving the next package and then just pointing to a file within it that happened to be from react or a related package.

To get around this issue vendored packages are both committed in src and packed as a tgz file. Then in the next package.json we define these vendored packages as `optionalDependency` pointing to these tarballs. For yarn PnP these packed versions will get used and resolved rather than the locally commited src files. For other package managers the optional dependencies may or may not get installed but the resolution will still resolve to the checked in src files. This isn't a particularly satisfying implemenation and if pnpm were to be updated to have consistent behavior installing from tarballs we could actually move the vendoring entirely to dependencies and simplify our resolvers a fair bit. But this will require an upstream chagne in pnpm and would take time to propogate in the community since many use older versions

#### Upstream Changes

As part of this work I landed some other changes upstream that were necessary. One was to make our packing use `npm` to match our publishing step. This also allows us to pack `node_modules` folders which is normally not supported but is possible if you define the folder in the package.json's files property.

See: vercel#52563

Additionally nft did not provide a way to use the internal resolver if you were going to use the resolve hook so that is now exposed

See: vercel/nft#354

#### additional PR trivia
* When we prepare to make an isolated next install for integration tests we exclude node_modules by default so we have a special case to allow `/vendored/node_modules`

* The webpack module rules were refactored to be a little easier to reason about and while they do work as is it would be better for some of them to be wrapped in a `oneOf` rule however there is a bug in our css loader implementation that causes these oneOf rules to get deleted. We should fix this up in a followup to make the rules a little more robuts.


## Edits
* I removed `.sharedlayer` since this concept is leaky (not really related to the client/server boundary split) and it is getting refactored anyway soon into a precompiled runtime.
- reduce: `MISS`
- reduces: `HIT`
`normalizeNextData` in `next-server` used to exit early with a 404 when there was a build ID mismatch, but a recent refactor accidentally removed this functionality. This PR updates it to behave similarly to [web-server](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/web-server.ts#L180-L187) where we render404 if there's a mismatch.

[slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1691111541353749)
…docs. (vercel#53610)

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

-->
Updates `app-fetch-logging` tests to not start/stop the server each run and instead slice the relevant log output. Also moves log parsing inside of `check` since logs get appended asynchronously.

ref: https://github.com/vercel/next.js/actions/runs/5767647854/job/15637691191#step:28:662
This ensures the resolve calls for `styled-jsx` are done in the correct context so that tracing can include the correct symlinks/package.json files. 

x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1691217652833079)
Fixed a typo in the api reference about the [\<Image\> component](https://nextjs.org/docs/pages/api-reference/components/image#fill).

Replaced "stetch" with "stretch" in the fourth paragraph
Continues fix from vercel#53596 and
applies it for the `x-matched-path` specific code path.
This adds a workflow to auto update our fonts data so we can stay up to date easier. 

Closes: vercel#53246
Closes: vercel#53510
This auto-generated PR updates font data with latest available

Co-authored-by: vercel-release-bot <infra+release@vercel.com>
@shenlu89 shenlu89 changed the title Shenlu89 patch 1 Fix: missing equal sign Aug 7, 2023
@shenlu89 shenlu89 merged commit 2b6aa0c into canary Aug 7, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment