Updates our test config to take advantage of more concurrency and also
updates to leverage the playwright docker image to reduce flakes from
actions/setup-node stalling or playwright dependencies stalling on `apt
install`.
This reduces our test times from upwards of 30 minutes down to back
around 15 minutes.
After speaking with @timneutkens, this PR provides a smoother experience to users trying to migrate over to app without affecting users in pages.
This PR adds a new export available from `next/compat/router` that exposes a `useRouter()` hook that can be used in both `app/` and `pages/`. It differs from `next/router` in that it does not throw an error when the pages router is not mounted, and instead has a return type of `NextRouter | null`. This allows developers to convert components to support running in both `app/` and `pages/` as they are transitioning over to `app/`.
A component that before looked like this:
```tsx
import { useRouter } from 'next/router';
const MyComponent = () => {
const { isReady, query } = useRouter();
// ...
};
```
Will error when converted over to `next/compat/router`, as `null` cannot be destructured. Instead, developers will be able to take advantage of new hooks:
```tsx
import { useEffect } from 'react';
import { useRouter } from 'next/compat/router';
import { useSearchParams } from 'next/navigation';
const MyComponent = () => {
const router = useRouter() // may be null or a NextRouter instance
const searchParams = useSearchParams()
useEffect(() => {
if (router && !router.isReady) {
return
}
// In `app/`, searchParams will be ready immediately with the values, in
// `pages/` it will be available after the router is ready.
const search = searchParams.get('search')
// ...
}, [router, searchParams])
// ...
}
```
This component will now work in both `pages/` and `app/`. When the component is no longer used in `pages/`, you can remove the references to the compat router:
```tsx
import { useSearchParams } from 'next/navigation';
const MyComponent = () => {
const searchParams = useSearchParams()
// As this component is only used in `app/`, the compat router can be removed.
const search = searchParams.get('search')
// ...
}
```
Note that as of Next.js 13, calling `useRouter` from `next/router` will throw an error when not mounted. This now includes an error page that can be used to assist developers.
We hope to introduce a codemod that can convert instances of your `useRouter` from `next/router` to `next/compat/router` in the future.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This adapts the new client hooks of `usePathname`, `useSearchParams`,
and `useRouter` to work within the `pages/` directory to aid users
attempting to migrate shared components over to the `app/` directory.
> **Exception:**
> When the pages router is not ready, `useSearchParams` will return an
empty `URLSearchParams`. This mirrors the behavior seen in the `pages/`
directory today in that `router.query` is not available until the client
hydrates.
This also adds a new option for `useRouter` to bring it line with the
correct typings with the app directory. By default, calling
`useRouter()` will return the type `NextRouter | null` to represent what
you get when you call it from a component originating from the app
directory. If you want to instead force it to return `NextRouter` as it
does today, you can pass a boolean into the `useRouter` call as such:
```ts
const router = useRouter() // typeof router === NextRouter | null
const router = useRouter(true) // typeof router === NextRouter
```
This change is designed to ease the incremental adoption of app.
- Enable newNextLinkBehavior. See #36436
- Run next/link codemod on test suite
Note that from when this lands on apps trying canary will need to run
the new-link codemod in order to upgrade.
Ideally we have to detect `<a>` while rendering the new link and warn
for it.
Co-authored-by: Steven <steven@ceriously.com>
This PR introduces breaking changes by renaming components.
- Rename `next/image` to `next/legacy/image`
- Rename `next/future/image` to `next/image`
The diff is very confusing because both components are very similar so git got confused.
An alternative solution to #40371
Ref: #38867, https://github.com/t3-oss/create-t3-app/issues/412,
https://github.com/t3-oss/create-t3-app/pull/414
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The PR fixes#37122, an issue introduced by #37105.
`next.config.js` might/will include functions (custom `webpack`, `generateBuildId`, `exportPathsMap`, etc.) that are not able to pass from the main thread to a worker. The PR fixes the issue by only passing primitive args to the worker.
There was a mistake in #32077 which imported a different module than _document in the _document .d.ts file. I found that we didn't have a test for a custom _document.tsx and _app.tsx with TypeScript, so I've added one that fails on canary and passes with this fix to ensure this does not happen in the future.
Fixes#32110
## 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`
Ability to provide a custom tsconfig file.
**Example Usage:**
```js
// next.config.js
module.exports = {
typescript: {
tsconfigPath: "myconfig.json"
}
}
```
## 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.
- [x] Related issues linked using [`fixes #23972 (discussion)`](https://github.com/vercel/next.js/discussions/23972)
- [x] Integration tests added
- [x] 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
In a previous PR, `getServerSideProps` was altered to support returning
`props` as a promise. This change updates the TS types to permit promises
as well, so you can write type `GetServerSideProps<Props>` instead of
`GetServerSideProps<Promise<Props>>`. e.g.:
```typescript
type Props = {
data: string
}
export const getServerSideProps: GetServerSideProps<Props> = async (
context
) => {
return {
props: (async function () {
return { data: 'some data' }
})(),
}
}
```
## Feature
- [x] 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`
- [x] 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`
on GetServerSidePropsContext and GetStaticPropsContext
As discussed on #21574 having a generic type will give it more flexibility and remove linting errors.
## 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 #21574
- [ ] 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`
This strongly types `Router.events.on` and `Router.events.off`. Previously the event type was `string` but now it's `'routeChangeStart' | 'beforeHistoryChange' | 'routeChangeComplete' | 'routeChangeError' | 'hashChangeStart' | 'hashChangeComplete'`
## Bug
- ~[ ] Related issues linked using `fixes #number`~
- [x] Integration tests added
Closes#25679Closes#23753Closes#15497
## Bug
- [x] fixes#24684
- [x] Integration tests added
Intentionally omitted changing the types for `GetServerSideProps` etc. as its imo less reasonable to leverage SSR with a sync `getServerSideProps`. Can of course change the type too if you consider that also a valid case.
This adds `InferredStaticProps` and `InferredServerSideProps` to the typings.
- [x] add types for type inference
- [x] add explanation to docs
- [ ] tests - are there any?
![inferred-props](https://user-images.githubusercontent.com/56154253/79068041-24bcab00-7cc4-11ea-8397-ed1b95fbeca7.gif)
### What does it do:
As an alternative to declaring your Types manually with:
```typescript
type Props = {
posts: Post[]
}
export const getStaticProps: GetStaticProps<Props> = () => ({
posts: await fetchMyPosts(),
})
export const MyComponent(props: Props) =>(
// ...
);
```
we can now also infer the prop types with
```typescript
export const getStaticProps = () => ({
// given fetchMyPosts() returns type Post[]
posts: await fetchMyPosts(),
})
export const MyComponent(props: InferredStaticProps<typeof getStaticProps>) =>(
// props.posts will be of type Post[]
);
```
### help / review wanted
- [ ] I am no typescript expert. Although the solution works as intended for me, someone with more knowledge could probably improve the types. Any edge cases I missed?
- [ ] are there any tests I should modify/ add?
* Fix type on NextApiHandler
The example [here](https://nextjs.org/docs/api-routes/api-middlewares) shows that `NextApiHandler` can be async, so the return type should be `void | Promise<void>`.
* Add TS integration tests for API
* Rename unstable GSP revalidate field
* Update error message
* Tweak error message some more
* Apply suggestions from code review
Co-Authored-By: Joe Haddad <joe.haddad@zeit.co>
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add a configuration flag to disable integrated type checker
* Add tests for typescript-transpileonly
* Restore removed argument
* Make output more coherent
* Split transpileOnly into ignoreDevErrors and ignoreBuildErrors
* Minor stylistic change
* TypeScript report on active pages only
The TypeScript integration needs to report on active pages only.
When inactive pages are reported, they block the compilation and prevent the user from fixing the error (because the file isn't watched).
We cannot add the file to the webpack watcher because the compilation has already been sealed.
* Remove TODO message
* Test that inactive pages are not type checked
* Tweak typescript test suite
* Revert "Tweak typescript test suite"
This reverts commit 9e0108da7c70e7ae45b412b60c07162383de65f3.
* Make sure HMR connection isn't being closed
while testing
* Update to not re-use NODE_ENV
* Break up/rework TypeScript test suite
* bump
* Added the RouteUrl type and improved router types
* Added more tests for router types
* Add build test for typescript types
* Add next-env.d.ts to the typescript test
* Removed next-env.d.ts
* Added next-env.d.ts to gitignore
* Remove route url re-exports
* renamed PublicRouterInstance to be NextRouter
* export the Url type
* Replaced BaseRouter with NextRouter in server/utils
* Don't export the Url type
* Update tsconfig.json
* Fix TypeScript typing
This correctly defines `process.browser` instead of `process.env.browser`.
It also removes `process.crossOrigin` because it's not found in our documentation anywhere and is mostly used for internal purposes.
* Make sure `process.browser` doesn't throw a type error
* Split globals from Next.js module
* Allow `test` as a valid NODE_ENV
* Fix type assignment
* Make sure global types get published
* Fix test