This fixes resolving `beforeFiles` rewrites with `next/link` as previously we weren't resolving the destination to a dynamic route since the resolving was being marked as finished when it shouldn't be during `beforeFiles`.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/35402
fix: #36329
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
x-ref: #36190
x-ref: #31506
* Move nodejs ptah module usage to next-server, keep base-server and web-server headless for `'path'`
* Use a native module `path` for nodejs runtime and `path` polyfill for edge runtime
Clarifies that the query object contains query and dynamic path parameters. As I was helping another engineer, I tried to reference this documention. I thought the routing page would be a more useful reference if it indicated how to read path parameters.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Fixes#35634
This change doesn't require tests as importing svgs is not a supported feature, this just makes it slightly more ergonomic to override the matchers.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
This adds a new test mode `next-deploy` which allows testing against deployments using the Vercel CLI. After running these tests they uncovered some bugs we need to correct before fully enabling. Patching the uncovered issues will be done in follow-up PRs and then after resolved this will be enabled to run after new publishes.
Tests that uncovered bugs to patch in follow-ups:
- [ ] test/e2e/getserversideprops/test/index.test.ts (req.url normalizing)
- [ ] test/e2e/i18n-api-support/index.test.ts (locale prefixed API routes matching)
- [ ] test/e2e/prerender.test.ts (/_next/data/build-id/ does not 404)
This ensures we strip ansi encoding from serialized errors as it causes the error to be illegible when rendered. This also adds a test for global CSS import being missing and then fixed.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This PR adds a small utility script for the existing `next/trace` converts emitted output into chromium's trace event format (https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview?mode=html#). Converted output can be loaded in a couple of visualizers that understand trace event format.
- `chrome://tracing`
- `https://ui.perfetto.dev/`
Technically it is possible to make generated event format to be compatible to chrome devtool's profiler as well, but that is not dealt with initial implementation.
This is very straightforward, naive conversion between generated trace to the specific format instead of trying to augment existing traces: in result, some of the values are dummy (pid, tid, category). Depends on usecases we can potentially expand & correct later if needed.
Below screenshot is perfetto from `bench/nested-deps`.
<img width="1166" alt="Screen Shot 2022-04-19 at 10 35 28 AM" src="https://user-images.githubusercontent.com/1210596/164062522-4d34a8c0-d66a-4c9e-9e15-08e0cd6d41a7.png">
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
## Description
The Yoga design system follows design guidelines specification, we developed a React and React Native UI library that contains a set of high-quality components that defines our interfaces.
- https://github.com/Gympass/yoga
- https://gympass.github.io/yoga/
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Fix line in link to interface `NextConfig` where describe `next.config.js` properties.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
There wasn't a strong reason to choose `renderToStream` over `renderToStaticMarkup` for the document wrapper. But due to problems like #35870, we can switch back to the static renderer for now.
Fixes#35870.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [X] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This PR fixes#36247 by adding the optional `options` object to the type definition for `DocumentContext.defaultGetInitialProps`.
This PR attempts to fix#31855, by loosening conditions to determine what to drop when swc runs transform. Currently, it drops all the export declaration if it's being referenced only in getstatic* in local scope. But as `export` implies, there's no guarantee given export will be used in other modules even if it's not being used in local scope. PR tries to not to drop exports declarations as much if it's not being used locally other than getstatic*. This makes dropping bit ineffecient, but as long as we can't cross-ref across modules that's something unavoidable in my opinion.
I don't think implementation itself is quite acceptable: probably need review & revise to the logics.
## Bug
- Attempt to close#31855
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
#33097 adds a note to the `Script` documentation explaining that `onLoad` cannot be used with the `beforeInteractive` strategy. However, this note was missing in the [Basic Features](https://nextjs.org/docs/basic-features/script) documentation, causing some confusion. This adds the note there too.
This will hopefully fix a lot of confusion noted in https://github.com/vercel/next.js/issues/33191.
Previously we made the cache key specific to each run attempt to allow having a separate cache in case a previous build cache was incorrect but now that actions allow re-running only failed it seems more beneficial to allow re-using the build cache for the re-run and for cases where the build cache is incorrect a `bump` commit can be done instead.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
* Fix build activity indicator position
`devIndicators.buildActivityPosition` introduced in
https://github.com/vercel/next.js/pull/30109 needed more tweaks to properly
position the build indicator container. The build indicator was being rendered
off screen when set to a non-default position.
* Refactor stuff for smaller diff
* add config validation
* Apply suggestions from code review
Co-authored-by: Martin Šťovíček <martin.stovicek@monitora.cz>
I would like to be able to write handlers with early returns like this:
```typescript
import { NextApiHandler } from 'next'
const handler: NextApiHandler = (req, res) => {
const value = getStuff()
if (value === 'branch') {
return res.json({})
}
res.status(400)
}
```
but `NextApiHandler`'s current return type is `void | Promise<void>`, which causes compilation to fail with
```
Error:(11, 3) TS2322: Type '(req: NextApiRequest, res: NextApiResponse<any>) => Promise<NextApiResponse<any> | undefined>' is not assignable to type 'NextApiHandler<any>'.
Type 'Promise<NextApiResponse<any> | undefined>' is not assignable to type 'void | Promise<void>'.
Type 'Promise<NextApiResponse<any> | undefined>' is not assignable to type 'Promise<void>'.
Type 'NextApiResponse<any> | undefined' is not assignable to type 'void'.
Type 'NextApiResponse<any>' is not assignable to type 'void'.
```
to avoid that the above snippet needs to be written as
```typescript
if (value === 'branch') {
res.json({})
return
}
```
which looks odd to me. Changing the return type of `NextApiHandler` to `unknown | Promise<unknown>` would allow for shorter early returns and still communicates to users that nothing is expected to be returned from a handler.
Augmenting the type like this, makes the first snippet work:
```typescript
import { NextApiRequest, NextApiResponse } from 'next'
declare module 'next' {
export declare type NextApiHandler<T = any> = (
req: NextApiRequest,
res: NextApiResponse<T>
) => unknown | Promise<unknown>
}
```
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
## Bug
The custom app is missing in the `ctx.AppTree` that causing the issue, it was accidently missed in custom _app.server pr #35666Fixes#36198
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
This PR fixes the wrong path to creating an app using the `with-emotion-swc` example.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
we can import server or client components in any server component, not from it.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
fixes#35784
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Even though we never documented it, the `onLoad` prop used to work (in most cases) in Next.js 12.1.4 and broke in 12.1.5 once the code was refactored in PR #35889.
We still shouldn't document it because `onLoad` doesn't work in all cases so [`onLoadingComplete`](https://nextjs.org/docs/api-reference/next/image#onloadingcomplete) is preferred, however tests were added for the cases that do work.
Use cases that don't work with `onLoad` are Data URLs as well as `loading="eager"`.
Continuation of #33592 with updates tests / changes.
Co-Authored-By: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order 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 that you're making:
--
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
** I've made the change via GitHub UI sorry :)**
Hi,
I think the "data must be public" condition on getSSP is not really true, and even counter-productive. Being able to statically render more content is most probably positive, in terms of perceived and real performance of the app + energy consumption. It's actually totally possible, and not even that hard thanks to middleware, to statically render custom, paid, segment-specific content (and even individual-specific content under certain conditions).
I've documented the reason for this change in a few places if you want more details:
- related PR on React: https://github.com/reactjs/reactjs.org/pull/4566
- demo implementation and explanation on how to couple middlewares and getSSP to statically render any kind of content (including custom content): https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde
