Revert some code in #47379 and finalize HOC support. We should require
the HOC to return a "use server" function, so there's no need to compile
the function call specially now.
To make that wrapping logic work, we need to allow passing a server
reference to another server reference. This usually happens in the
function closure in the HOC case, but ideally it's also allowed to
directly pass it as an argument. This requires adding React server DOM's
`encodeReply` and `decodeReply` and other corresponding changes,
including adding `busboy` (can probably be vendored?) as we need to
parse the multipart body now.
fix NEXT-808 ([link](https://linear.app/vercel/issue/NEXT-808))
([link](https://linear.app/vercel/issue/NEXT-808))
### What?
introduce a new hook `useReportWebVitals` that would register a function to handle web-vitals metrics.
### Why?
next.js users who use [Axiom](https://axiom.co) has been [asking](https://github.com/axiomhq/next-axiom/issues/109) for this feature for nextjs 13, as it was working for nextjs 12.
This PR adds Zod to the precompiled libraries, and use it to create schemas for the router state tree for validation. In other planned features/changes, Zod will also be used to do run-time data validation.
Fixes NEXT-135.
fixes NEXT-479
## content
This PR adds a `getTracer` API to Next.js that uses the `otel/api` under
the hood to provide Next.js level instrumentation through Open
Telemetry.
This also adds an example `with-opentelemetry` to demonstrate how it can
be used, assuming you have a collector.
This allows most notably to have `getServerSideProps` and `fetch` calls
inside Server Components traced.
## details
- we hide most internals spans, if you want to see all of them, use the
NEXT_OTEL_VERBOSE=1 env var
- if you want to use this, you'll need to rely on the
`config.experimental.instrumentationHook` config option to initialise
OTEL, like in the example
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
This adds `loader-runner` to the compiled packages distributed with
Next.js
This is a dependency of Turbopack's webpack loader support. Currently,
users have to manually install `loader-runner` in their application to
use webpack loaders with Turbopack. This will allow Turbopack to require
loader-runner from within the installed version of Next.js instead.
Test Plan: `require('./packages/next/dist/compiled/loader-runner/')`
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
When you're trying to migrate an application from `pages/` to `app/`,
you'll need to access data like search parameters and the pathname in a
way that lets you migrate safely.
This adds support for dynamic typing of some of those exported functions
from `next/navigation`, namely `useSearchParams` and `usePathname`.
Currently, `searchParams` can’t be known when prerendering if the page
doesn’t use [Server-side
Rendering](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props)
in the `pages/` directory. `pathname` can’t be known during prerendering
if the page is a fallback page or has been automatically statically
optimized when accessed from `pages/`.
To make migraitons easier, this adds a new feature to `next dev` that
will automatically add the correct types for `next/navigation`. It does
this by checking if you have both a `app/` and `pages/` directory. If it
detects you have a `app/` directory, it will also enable the suggested
Typescript feature,
[`structNullChecks`](https://www.typescriptlang.org/tsconfig#strictNullChecks)
which will warn developers when trying to access a value that may be
`null`.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The PR upgrades `cross-spawn` to `7.0.3`. The precompiled has also been
updated. The `cross-spawn` version is still pinned after the PR.
-----
So I have been working on improving Next.js build performance recently.
One thing that catches my eye is this:
<img width="1751" alt="image"
src="https://user-images.githubusercontent.com/40715044/218383194-5b24c737-0d97-4434-bbbf-ba5752072882.png">
The flamegraph shows the `semver` inside `cross-spawn` is one of the
hottest functions.
Then I take a look at the `cross-spawn`, turns out that `cross-spawn`
has `semver` already removed:
https://github.com/moxystudio/node-cross-spawn/pull/125
According to the CHANGELOG of `cross-spawn`, the only breaking change is
that `cross-spawn@7` is dropping `Node.js < 8` support. So I assume it
would be fine to upgrade `cross-spawn` to the latest version `7.0.3`,
thus eliminating the extra performance overhead introduced by `semver`.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
