Added install instructions for eslint-config-prettier before adding Prettier to the ESLint config.
## 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
…/image` Error
While learning how to test next.js applications I came across this error when testing components using next/image with an image import
eg:
```
// /quiz-hero
import Image from 'next/image';
import quizImage from '../../public/undraw-quiz.svg';
// In render
<Image
height='91'
width='198'
layout='fixed'
src={quizImage}
alt='QuizImage'
/>
```
### Error ->
Failed to parse src "test-file-stub" on `next/image`, if using relative image it must start with a leading slash "/" or be an absolute URL (http:// or https://)
This is fixed by adding a "/" to the beginning of your file-stub module export string.
This is not an error when you're awaiting an image using async waitFor, But comes up as an error when you're testing a component that holds another component with a "next/image" import.
eg:
```
// quizHero.test.tsx works like this without change.
const image = await waitFor(() => screen.findByAltText('QuizImage'));
// but index.test.tsx fails rendering the homepage without the change.
render(<Home />); // Error: Failed to parse src "test-file-stub" on `next/image`...
// with change to __mocks__/fileMock
quizHero.test.tsx //test pass
index.test.tsx //test pass
```
<!--
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:
-->
## Bug
possibly related to -> #26749
## Feature
- [X] Documentation added
## Documentation / Examples
- [X] Make sure the linting passes
## Bug
- [x] Related issues linked using Fixes: https://github.com/vercel/front/issues/11154
- [ ] 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
- [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
- [ ] Make sure the linting passes
* The previous `npm run jest` command did not match up with the testing script added to the example `package.json`
* Fixes#29777
## Bug
- [x] Related issues linked using `fixes #number`
- [N/A] Integration tests added
- [N/A] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
## 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
This PR contains an overhaul of the image component documentation for next (both the [primary usage doc](https://nextjs.org/docs/basic-features/image-optimization) and the [API reference](https://nextjs.org/docs/api-reference/next/image)). This PR does not change the filepath/URL for either of those documents, but that may still be warranted as right now Google searches for "next.js image component" and the like return the API document as the first result, which is not optimal.
The changes to the docs are based on feedback from the community and with input from @leerob. I'm marking this PR a draft because we will likely want to have a round of revisions before merging, but in general I consider this PR "read to go," contingent on buy-in from other stakeholders.
The basic goal of the changes are as follows:
1. Simplify the getting started page by moving extraneous detail to the API documentation.
2. Refocus the getting started page on practical usage information
3. Add additional content to address issues that have come up as common pain-points around the image component, such as image sizing and styling.
Fixes#21786
CC: @styfle @timneutkens @kara @spanicker
Fix a small error in the `next/script` docs.
Let me know if you'd like a `useState` for the sake of a complete 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
- [ ] Make sure the linting passes
`getInitialProps` is already being referenced on the [Custom `App`][1] page, since it's the only supported data-fetching method for custom `App` components, but folks who started using Next.js after the advent of `getStaticProps` and `getServerSideProps` may not be familiar with the `getInitialProps` API.
[1]: https://nextjs.org/docs/advanced-features/custom-app
## Documentation / Examples
- [x] Make sure the linting passes
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
* Update headings to clarify that we're describing. Add heading for Authentication API Routes
* Start adding API route examples
* Start adding API route examples
* Start adding API route examples
* Start adding API route examples
* auth: Replace clerk packages with @clerk/nextjs
* Add API authentication example to with-clerk
* Fix footer links
* Proofread, ensure consistency
* Update example's props to use new version
* Update example links
* Add rel tag to _blank link
* Obscure the authentication provider in the example
* Replace example
* Reset authentication docs, list Clerk as vendor
* Re-fix typo
* Change sample to example
* Add the example
* Update examples/with-clerk/package.json
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: Peter Perlepes <p.perlepes@gmail.com>
Co-authored-by: Lee Robinson <me@leerob.io>
Fixes#16442
The current instructions on the Debugging page currently only work for server-side code, and furthermore, the page doesn't actually _say_ that they only work for server-side code.
This update adds instructions for debugging client-side code in both VS Code and Chrome DevTools. It also improves the suggested VS Code launch configurations to take advantages of some relatively recent features in VS Code's [built-in JavaScript debugger][1]. Using the `node-terminal` and `pwa-chrome` launch types removes the need to manually pass an `--inspect` flag to the underlying Node.js process.
[1]: https://github.com/microsoft/vscode-js-debug
Let me know if there are any edge cases I didn't consider with these VS Code launch configs!
## Documentation / Examples
- [x] Make sure the linting passes
I also removed the custom server link here, because I think it's making too strong of a correlation between custom server and Node.js server using `next start`, which aren't the same.
## 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
Added () outside *demo"
## 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
Changed - function component to - functional component in the heading and sentence below:
If the child of `Link` is a functional component, in addition to using `passHref`, you must wrap the component
## 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
I found that an example for a redirect rule in the documentation doesn't have the required property `permanent`. I noticed this because I tried to use that same rule but building fails with the following message:
```
`permanent` is not set to `true` or `false` for route {"source":"/:path((?!another-page$).*)","has":[{"type":"host","value":"example.com"}],"destination":"/another-page"}
Error: Invalid redirect found
```
My PR simply adds the missing `permanent` property as false to be consistent with the rest.
## Documentation / Examples
- [x] Make sure the linting passes
In talking to partners, I've seen a lot of confusion about the number of wrapping `<div>`s around the image element rendered by `next/image`. There's always just one single wrapper--this PR updates the docs to make that a little more explicit.
Current docs on exposing environment variables to the browser are slightly misleading as they say that variables loaded from `.env.local` are only available in node by default, but this is the case for all environment variables not just those loaded from `.env.local`.
## Documentation
- [x] Make sure the linting passes
Previous to this change, getServerSideProps could only return plain objects
for props, e.g.:
```javascript
export async function getServerSideProps() {
return {
props: {
text: 'some value',
}
}
}
```
With this commit, the props object can also be a Promise, e.g.
```javascript
export async function getServerSideProps() {
return {
props: (async function () {
return {
text: 'promise value',
}
})(),
}
}
```
For now, the framework simply waits for the results of the props Promise to resolve,
but this small change sets the groundwork for later allowing props to be streamed (cc @devknoll).
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. -- *This is part of @devknoll's ongoing work to support streaming.*
- [ ] 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. *not sure if this applies here*
- [ ] Errors have helpful link attached, see `contributing.md`
"exclusive of" implies that it doesn't pertain to `export` https://www.merriam-webster.com/dictionary/exclusive%20of "Exclusive to" implies that it's only relevant to `export`.
Also changed "can not" to "cannot".
## 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