Fixing a simple case sensitivity error in the import statement,
"storeProvider" should be "StoreProvider".
Co-authored-by: Steven <steven@ceriously.com>
## What?
Fixes the `should update server components pages when env files is
changed (edge)` tests. In order for changes to the environment to apply
to edge-runtime routes we need to call `clearModuleContext`, currently
that only supports a single path being provided, but in Turobpack the
compilation is much more granular than webpack, in case of webpack we
loop through all items coming out of the compilation and invalidate them
regardless, which is not needed for Turbopack. Instead, when an
entrypoint (route) is recompiled it'll automatically only invalidate
that part. For `.env` changes that don't affect compilation, which is
what the test checks, this wouldn't be sufficient as there is no
compilation difference between changing those env vars. In the case that
you change `.env` / tsconfig/jsconfig we have to clear all module
contexts, which is what this PR implements.
<!-- 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 #
-->
Closes NEXT-2337
### What?
We need the manifest to pass a bunch of preloading tests.
Currently, this is just a dumb implementation that preloads all fonts
and always sets size-adjust to true.
Google fonts are also still requested from Google directly it seems and
therefore never preloaded.
### Adding or Updating Examples
- Example:
[with-docker](https://github.com/vercel/next.js/tree/canary/examples/with-docker)
- Update: The latest change introduced in #61466 on the building process
of NextJS when the package manager is PNPM is currently throwing an
error (it works for npm though).
**To replicate the error:**
1. Checkout on the **with-docker** example
2. Install with PNPM so that it generates the pnpm-lock.yaml
3. Build the Docker image -> This will fail on the _builder stage_ step
that runs `pnpm run build`.
**Possible Solution:**
- Run `corepack enable pnpm` before building with pnpm
## What?
Whenever `.env` related files or tsconfig/jsconfig changes there's a
call to `invalidate()`, as far as I found the only call to
`invalidate()` even, which wasn't implemented for Turbopack yet. For
`NEXT_PUBLIC_` changes normal Turbopack HMR will kick in already but
this test was checking env vars that do not affect the compiled output,
so Turbopack would not trigger a HMR as no inputs changed. Similarly
webpack doesn't either and it implements this call in a similar way.
For edge runtime there's a different bug where changes are not
propagated even when you refresh, so while this change does fix another
bug for edge runtime it doesn't solve that underlying issue where the
values don't update to begin with. I'll investigate that next.
<!-- 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 #
-->
Follow up for #61463
Basically the fix in #61463 was not correct. I added a log to see which
react is resolved in `dynmiac-rendering` module, and the got this:
The module with incorrect react version is from
`next.js/packages/next/dist/compiled/next-server/app-route.runtime.prod.js`
which resolves `react` as `./dist/compiled/react/index.js` even
experimental react should pop in here.
Then I found the app-route runtime doesn't have check for the react exp
env, then I added there to make it aligned with app-page runtime
Closes NEXT-2327
Closes NEXT-2294
## What?
Fixes one of the styled-components tests. Somehow the test that checks
the warning shows up without the transform is not showing the warning
but the transform is also not enabled, so I've skipped the test as it's
not important for stable.
<!-- 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 #
-->
Closes NEXT-2321
### What
The `arg` in the worker callback is alwasy `any`, when we access the
page path the argument could be in different form as the arg types are
different.
This PR align the argument type to object for `isPageStatic`,
`getDefinedNamedExports`, `hasCustomGetInitialProps` methods in static
worker. So they can share the similar shape of type of argument when
accessing `page` path. This will avoid the case that logged `page` in
the warning is `undefined`
Import the helpers from utils instead of workers as the worker itself
don't need to contain other exports that is not used for static worker.
### Why
This PR align the callback type of callback argument type of static
worker, so that we could get the actual page path value in a type-safe
way. We have 4 methods for static worker, `exportPage`, `isPageStatic`,
`getDefinedNamedExports`, `hasCustomGetInitialProps`, which the rest of
3 methods share the same format of warnings but their argument are
different. It's easily ended up with wrong argument type, and log with a
bad page path in the warning.
Closes NEXT-2289
### What?
This adds a method to optionally detect disk, network, and env access
access during a build and write this to a file.
### Why?
This will be consumed by Turborepo to determine **if** a build can be
cached, and if so, **how** it should be cached.
### How?
This implements a proxy that can be selectively applied to functions to
watch their access to disk, network, and env. For Turborepo, we only
care about what can alter the build output, to achieve this, we trace
the config load, and the static page generation.
Closes
https://linear.app/vercel/issue/TURBO-1904/support-build-access-tracing-in-nextjs
Performance Testing:
Repo -
https://github.com/tknickman/nextjs-turborepo-build-trace-performance-testing
```
- - - - - - - - - - - - - - - - - Performance - - - - - - - - - - - - - - - - -
pages-single-app:
44629.53301 ms (+/- 6313.82757 ms) from 5 iterations (223318.53692 ms total)
local-pages-single-app-with-trace:
45684.00503 ms (+/- 6570.85083 ms) from 5 iterations (228585.01729 ms total)
local-pages-single-app-without-trace:
45938.76231 ms (+/- 6816.13022 ms) from 5 iterations (229830.15925 ms total)
approuter-single-app:
49517.23156 ms (+/- 7820.20687 ms) from 5 iterations (247725.16713 ms total)
local-approuter-single-app-with-trace:
50019.98247 ms (+/- 9443.82537 ms) from 5 iterations (250224.62496 ms total)
local-approuter-single-app-without-trace:
50124.07092 ms (+/- 9656.22047 ms) from 5 iterations (250726.35688 ms total)
local-large-pages-single-app-without-trace:
51582.92992 ms (+/- 12179.09895 ms) from 5 iterations (258469.36942 ms total)
local-large-pages-single-app-with-trace:
51740.25813 ms (+/- 12601.02878 ms) from 5 iterations (259329.50946 ms total)
local-xlarge-pages-single-app-with-trace:
234111.66735 ms (+/- 74629.30509 ms) from 5 iterations (1191018.63608 ms total)
local-xlarge-pages-single-app-without-trace:
239621.11837 ms (+/- 84629.16374 ms) from 5 iterations (1218078.41921 ms total)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
```
<details>
<summary>Test case keys</summary>
* `local-xlarge-pages-single-app-without-trace`: this branch, built and
linked to a local project with 5000 SSG pages and trace **disabled**
* `local-xlarge-pages-single-app-with-trace`: this branch, built and
linked to a local project with 5000 SSG pages and trace **enabled**
* `local-large-pages-single-app-with-trace`: this branch, built and
linked to a local project with 100 SSG pages and trace **enabled**
* `local-large-pages-single-app-without-trace`: this branch, built and
linked to a local project with 100 SSG pages and trace **disabled**
* `local-approuter-single-app-without-trace`: this branch, built and
linked to a local default approuter starter and trace **disabled**
* `local-approuter-single-app-with-trace`: this branch, built and linked
to a local default approuter starter and trace **enabled**
* `local-pages-single-app-with-trace`: this branch, built and linked to
a local default pages starter and trace **enabled**
* `local-pages-single-app-without-trace`: this branch, built and linked
to a local default pages starter and trace **disabled**
* `approuter-single-app`: next@latest running on the default approuter
starter
* `pages-single-app`: next@latest running on the default pages starter
</details>
TODO:
- [ ] Telemetry events
This ensures we don't do un-necessary IPC calls during image optimizing
and leverage the internal request handler for fetching internal static
images/resources.
x-ref: https://github.com/vercel/next.js/issues/58248
Closes NEXT-2318
### What?
avoid sending issues turbopack messages to browser
### Why?
they trigger fake HMR events and are not used on client side anyway
Closes PACK-2338
Since we do not optimize videos, we do not need to add the hostname to
the `next.config.js` file. This PR removes the note telling the reader
to do this.
### What
When using a default slot that re-exports another page, the CSS entries
(and presumably other client reference modules, like JS entries) that
correspond with the re-exported page won't be loaded, resulting in CSS
styles not being applied.
### Why
`next-app-loader` constructs the path to the default segment but special
cases the `children` slot (which is used as the page), to mark the
segment as an empty string. This is so that the parallel default file
can be loaded. However the way that `defaultPath` is constructed, it
assumes that `actualSegment` won't be an empty string, and constructs an
invalid path like so:
`app/example//default.tsx`
When we go to look up the JS/CSS entries from the client reference
manifest, the key will be incorrect and so it won't find the files for
it, resulting in this bug.
### How
This moves the `/` delimiting to be part of the creation of the
`actualSegment` variable so that we only append it when we know we
aren't setting it to be an empty string.
Fixes#52245Fixes#49871
Closes NEXT-2309
Closes NEXT-2310
### What?
On windows the .git/* files are read only, when the CNA "import path" script attempts to open one of the .git/* files
### Why?
attempting to open any of the .git/* files results in an error thrown by CNA and CNA exists, hence not finishing the setup of a new project
### How?
My suggested fix uses the fast-glob ignore option to exclude the .git folder, I also moved the the ts(js)config.json exclusion into the ignore (was an "if" before)
- Fixes#61411
- Discussion https://github.com/vercel/next.js/discussions/61261
When using `next/dynamic` in server components to load a client
component with named export, we shouldn't dot into the prop name since
client component reference as it's already a valid react component type.
It would work with `default` prop but not other named exports.
Let's say `mod` is a dynamic imported module
```
mod.Button.default
```
will become the client reference key
```
mod#Button#default
```
Which means in module `mod`, get `Button` export, then `default`
property of it, which is wrong but it's a valid key in the client
reference roxy.
This PR checks if they're client module, then return itself as dynamic
imported component type for `next/dynamic` if it is one.
Fixes#61046
Closes NEXT-2229
### What?
Avoid a dependency from the emit operation to the `get_and_write`
lookup.
### Why?
This makes HMR much faster since the `get_internal` method is pretty
slow.
Closes PACK-2337
### What?
- Add a comment to issues labeled with `resolved`
Note to maintainers: it won't autoclose the issue. (This would need to
be added to [`nissuer`](https://github.com/balazsorban44/nissuer) as a
new feature)
Rendered comment
[here](b868cf95f2/.github/good-first-issue.md)
- I also reorganized the label comments to its own folder since we have
a few now.
### Why?
After verifying if an open issue has been fixed, a common task is to
comment on it and tell people to upgrade or open a new issue if it
persists. (Ideally, PRs would reference every issue they fix, but
sometimes we need to do this chore manually)
### How?
Using `nissuer`'s
[comment-label](https://github.com/balazsorban44/nissuer#label-management).
Closes NEXT-2306
### What
Catch-all parallel slots were being incorrectly matched to the root of their segment. For example, `@foo/[...catchAll]/page` as a parallel route on `/page.tsx` should not match on `/`, but it should match on `/foo`, `/bar`, ...etc
### Why
The catch-all route normalization logic doesn't treat optional catch-all routes differently from catch-all routes. The assumption was if any catch-all route was found, that it should match the path that shared its prefix.
### How
This updates the normalization logic to handle optional-catchall as it was in the original implementation. For regular catch-all, we ensure that the catch-all base path (for `/[...slug]` that'd be `/`) isn't identical to the path we'd match it to.
Fixes#60613
Closes NEXT-2243
