Based on user feedback, this clarifies the difference between rewrites and redirects, as well as follows the new pattern for showing version history with a collapsible table.
The guides for `next.config.js` never specify that the `has: { }` syntax is only available for v10.1, and not for v10.0. Add a note that indicates these features are only available in the latest version.
## Documentation / Examples
- [x] Make sure the linting passes
This updates this initial PR here https://github.com/vercel/next.js/pull/18146 to resolve merge conflicts and updates tests since we aren't able to update that PR itself.
## 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`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
Closes: https://github.com/vercel/next.js/pull/18146
The docs were vague on this -- `router.asPath` mentions that it doesn't include `basePath` but `router.pathname` didn't say either way.
## Documentation / Examples
- [ ] Make sure the linting passes: I haven't checked; I presume you have a CI bot for this.
- Since SuperTokens is a self hosted solution, it can be added to 'Bring Your Own Database' as well (in https://nextjs.org/docs/authentication#supertokens)
- Improvements to code structure in the with-supertokens example
added the following line, to remove the size of the `runner` (production) image. This will remove the `devDependencies` from the container after `next build` completes.
```
yarn install --production --ignore-scripts --prefer-offline
```
For the typescript starter, this is the change in size
| before <br/>proposed change<br/>size in bytes | after <br/> proposed change <br/> size in bytes|
|----|---|
| 347MB | 176MB |
As far as I know `notFound` supports use cases like a post getting permanently removed from CMS (thus should not exist on the webpage anymore) without a redeploy.
If the above statement is correct I believe this should be mentioned in the docs as it seems like a common use case and quite a few questions about this are floating around in the GitHub Discussions too.
I've recently built an i18n library that is tailored to usage in Next.js: [next-intl](https://github.com/amannn/next-intl). It complements the internationalized routing capabilities of Next.js by managing translations and providing them to components, as well as handling date and time formatting. It's a bit young, but I'm using it in two production apps now and I'm quite confident in the library.
Would you want to include an example and link to it?
Non-interactive elements such as a `<span>` should not have event bindings as they are not accessible by everyone.
This fix solves this issue by replacing it with a `<button>` which is suitable for interaction.
Since a button defaults to `type="submit"` the button also explicitly has a `type="button"` to prevent accidental form submits (all examples aim to navigate, not to submit a form).
[More background on this a11y best practice](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/HEAD/docs/rules/no-static-element-interactions.md)
This updates the incremental adoption section in the rewrites docs to mention the new fallback rewrites instead of the no-op rewrite and also points to the incrementally adopting Next.js doc.
## Documentation / Examples
- [x] Make sure the linting passes
Closes: https://github.com/vercel/next.js/pull/23700
Closes: https://github.com/vercel/next.js/issues/23699
It took me quite a while to understand that in order to redirect from `/english(default)/:path` to `/en-us/:path`, I have to escape the parentheses in the source with double backslashes so I thought I'd suggest it as a small doc update.
## Documentation / Examples
- [x] Make sure the linting passes
Added the fact that when `prefetch` is set to `false`, Next will prefetch the link when an `onMouseEnter` is triggered. Response to issue #11793
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [X] Make sure the linting passes
Closes: https://github.com/vercel/next.js/issues/23525
This is a follow-up to https://github.com/vercel/next.js/pull/23588 to update to use a regex lexer to gather the named regex groups instead of attempting to gather them through executing the regex since it can fail to gather the regex groups when they are using specific matching. This also ensures we don't pass the value as a segment when value is defined and it doesn't use a capture group. Additional tests are added to cover these cases and documentation updated to reflect this.
Closes: https://github.com/vercel/next.js/issues/23415
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
## Documentation / Examples
- [x] Make sure the linting passes
This is a one-line commit, which adds the missing import for VisuallyHidden component, from Reach UI, to the CSS documentation in the Dialog component example.
This updates the incremental migration doc to mention the new fallback rewrites over the previous no-op rewrite behavior. This also mentions the version the new rewrites modes were added to the rewrites doc.
## Documentation / Examples
- [x] Make sure the linting passes
This adds a note the `has` documentation mentioning the feature is still experimental as we currently show a warning when the feature is used stating the same.
## Documentation / Examples
- [x] Make sure the linting passes
Fixes#23687
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [x] Make sure the linting passes
This pull request **temporarily** removes ESLint, as it was not landed in accordance with our standard experimental policies. We are fully committed to landing this change again.
This is being reverted because:
- Next.js has very strict goals for its install size. This feature resulted in adding over 17MB, or a 43.6% increase.
- The feature was not first landed under the `experimental` key in `next.config.js`, rather, it was added under the stable namespace (top-level)
- Using the feature doesn't do a "guided setup" like TypeScript, it should ask you to "bring your own" dependencies for ESLint
- It uses a undesirable ESLint plugin name: `plugin:@next/next/recommended`. This should read out as strictly `next`, or as short as we can get it.
- Does not provide actionable warnings (missing link to resolve issue)
- Does not follow appropriate console output styling. We need to revisit how these are presented.
To re-land this, we need to ensure the following minimums are met:
- Very minor change in install size
- Fully experimental (i.e. flagged) with warnings
- Finalized package name and configuration shape, preferably so we can do ` { extends: 'next' } `.
## 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
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [x] Make sure the linting passes
## Documentation / Examples
- [x] Make sure the linting passes
`router.pathname` can be dynamic routes like `/posts/[slug]`, use `router.asPath` instead to detect anchor is active
## 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
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [x] Make sure the linting passes
This adds support for returning an object from `rewrites` in `next.config.js` with `beforeFiles`, `afterFiles`, and `fallback` to allow specifying rewrites at different stages of routing. The existing support for returning an array for rewrites is still supported and behaves the same way. The documentation has been updated to include information on these new stages that can be rewritten and removes the outdated note of rewrites not being able to override pages.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
This adds support for a `has` field to `rewrites`, `redirects`, and `headers` to allow matching against `header`, `cookie`, and `query` values. Documentation and additional tests for the feature is also added in this PR.
Closes: https://github.com/vercel/next.js/issues/22345
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
For #22228
This PR:
- Adds ESLint to toolchain
- Included by default for builds (`next build`)
- Can be enabled for development (`next dev`)
- Custom formatter built for output
- Adds appropriate tests
- Adds two documentation pages
Under the Single-Page App (SPA) heading, there is a code snipped which has a missing import:
import { useState } from 'react'
to
import { useState, useEffect } from 'react'
Also added apostrophe to description:
your old application entry point
to
your old application's entry point
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [X] Make sure the linting passes
Following commit https://github.com/vercel/next.js/commit/1f5c2c851333b5601cc1e9463253fdad0f0d8883
Adding documentation links to example.
## 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
- [X ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [x ] Make sure the linting passes
I've been this confusion quite a few times.
> So with my requirements, how big of a sin is it to use Next only for the frontend and get all its data, JWT tokens, etc. from my NodeJS backend by calling its respective APIs to said backend?
> Even the docs mention that running a custom server is not a great idea...
I thought that the current wording was not accurate both for next-iron-session and next-auth.
- next-auth is a full-featured authentication system like passport
- next-iron-session is a session utility
The previous copy was less clear about that and, for example, said you should go for next-iron-session for user/password and next-auth for everything else. Which is not the case. I use next-iron-session with only a Slack login, and you can implement email/password with next-auth.
Hope you like it!
PS: I have no preference between the two, I think they serve a different purpose. I used the two (and authored one).
I used next-auth on https://sourcekarma.vercel.app/