This PR adds the `poweredByHeader` and `webpack` fields to the public `NextConfig` type.
## 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
Fixes#27982
## 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
## Introduction
This PR enables setting a `rootDir` for a Next.js project, and follows the same pattern used by [`@typescript-eslint/parser`](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser#parseroptionsproject).
## Details
Previously, users had to pass paths to the rule itself.
```js
module.exports = {
rules: {
"@next/next/no-html-link-for-pages": [
"error",
// This could be a string, or array of strings.
"/packages/my-app/pages",
],
},
};
```
With this PR, this has been simplified (the previous implementation still works as expected).
```js
module.exports = {
settings: {
next: {
rootDir: "/packages/my-app",
},
},
rules: {
"@next/next/no-html-link-for-pages": "error",
},
};
```
Further, this rule allows the use of globs, again aligning with `@typescript-eslint/parser`.
```js
module.exports = {
settings: {
next: {
// Globs
rootDir: "/packages/*",
rootDir: "/packages/{app-a,app-b}",
// Arrays
rootDir: ["/app-a", "/app-b"],
// Arrays with globs
rootDir: ["/main-app", "/other-apps/*"],
},
};
```
This enables users to either provide per-workspace configuration with overrides, or to use globs for situations like monorepos where the apps share a domain (micro-frontends).
This doesn't solve, but improves https://github.com/vercel/next.js/issues/26330.
## Feature
- [x] 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 #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
Allows opting in to support for new concurrent features, like server-side Suspense.
**!!! DO NOT USE !!!**
This is highly experimental. We **will** be gating additional breaking changes behind this same flag.
**!!! DO NOT USE !!!**
Also resolves suspense for static pages (i.e. `getStaticProps` or `next build`/`next export`) since we can't currently support streaming for those cases anyway.
This PR adds a single data attribute to the image element generated by the image component `data-nimg`) which just serves to signal that this image element is from the component. Currently it's hard to quickly/programmatically determine with certainty whether an image is from the component or not, so this change should make it easier for us to diagnose and improve performance issues related to the image component.
I think the global `StaticImageData` type does not currently match what actually gets imported, and what the `Image` component expects (see [here](https://github.com/vercel/next.js/blob/canary/packages/next/client/image.tsx#L60-L65)). This PR changes `placeholder` to `blurDataURL`.
## 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
Upgrade styled-jsx to v4 for supporting concurrent mode in react 18
## 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 adds a type annotation for the `NextConfig` type to `next.config.js` in the `create-next-app` typescript template.
## 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
## Performance improvement
- [x] Performance improvement
Uses `fs.readdir`'s `withFileTypes` option, added in NodeJS version 10, to simultaneously read the target directories files and their stats, removing the need to call `fs.stat` on each of the files individually.
Similar to #27769, applies the same change to `recursiveCopy` and `recursiveDelete`.
* Update styed-jsx to latest version, containing bugfixes for babel plugin and typings.
* Use `/// <reference>` instead of redeclaring types
## 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
Documentation:
- Expands the "Migrating Existing Config" section of ESLint doc to explain in more detail
- Minor changes to the "Ignoring ESLint" doc
Bug fixes:
- Adds `browser` and `node` environments to `eslint-config-next`. Closes#26319
- Fixes `no-document-import` rule. Closes#26159
- Fixes `no-page-custom-font` rule. Closes#26160#26894
## Performance improvement
- [x] Performance improvement
Removes unnecessary `fs.stat` calls in `recursiveReadDir`.
`fs.readdir` had an option `withFileTypes: boolean` added NodeJS version 10. It can be used to read the directory contents and fetch its stats simultaneously, removing the need to read individual file stats after reading the directory contents.
This PR introduces an improved developer experience when `next lint` is run for the first time.
### Current behavior
`eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`:
Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues:
- Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`).
- #26348
- There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`.
- #26574
- #26475
- #26438
### New behavior
Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application.
<img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" />
- The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed
- Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`)
- For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config.
<img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png">
---
In addition, this PR also:
- Fixes#26348
- Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
This is a follow-up to https://github.com/vercel/next.js/pull/26963 which after discussion changes to interpolate the decoded variant of the value into the path.
x-ref: https://github.com/vercel/next.js/issues/24775
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
