This improves long term caching by avoiding hash changes
workaround fix#25013
The real problem is fixed by #24573
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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
This fixes ie11 compatibility that broke in https://github.com/vercel/next.js/pull/24656 from the polyfills not being loaded first, our existing ie11 test caught this but was failing, this ensures the test is passing again. This also updates the `hrefValue` optional chaining in the eslint plugin as these files aren't transpiled and related tests were failing in azure
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
This fixes an infinite redirect in the `has` redirect examples by ensuring not to match the redirect destination itself
## Documentation / Examples
- [x] Make sure the linting passes
emit must be called on build program to leverage caching
While the the current way of calling incremental typescript seem to work, it actually doesn't use caching correct. A difference is only notice-able on larger code bases...
Adds lint rules to the Next.js ESLint plugin to:
- Disallow importing `next/head` inside `pages/_document.js`
- Disallow importing `next/document` outside of `pages/_document.js`
Both rules will be surfaced as **errors** within the recommended config of the plugin.
Fixes#13712#13958
## Changes
- Update dependencies
- Use new `useAnimations` hook
- Remove next-transpile-modules in favour of drei
- Refactor Components
- Remove dynamic import
- Enable webpack5 (by removing `next.config.js`)
- Removed missing key warning
## 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
This example currently fails to build with the error:
```
-> % yarn build
yarn run v1.22.10
$ next build
warn - React 17.0.1 or newer will be required to leverage all of the upcoming features in Next.js 11. Read more: https://nextjs.org/docs/messages/react-version
info - Using webpack 5. Reason: no next.config.js https://nextjs.org/docs/messages/webpack5
Failed to compile.
./components/alert.tsx:2:16
Type error: Could not find a declaration file for module 'classnames'. '/Users/mike/workspace/blog/node_modules/classnames/index.js' implicitly has an 'any' type.
Try `npm i --save-dev @types/classnames` if it exists or add a new declaration (.d.ts) file containing `declare module 'classnames';`
1 | import Container from './container'
> 2 | import cn from 'classnames'
| ^
3 | import { EXAMPLE_PATH } from '../lib/constants'
4 |
5 | type Props = {
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
As of [`v2.3.1`](https://github.com/JedWatson/classnames/blob/master/HISTORY.md#v230--2021-04-01), the `classnames` package started providing its own types, so the `@types/classnames` package [became a stub](https://unpkg.com/browse/@types/classnames@2.3.1/). We get the error because the `classnames` version is pinned to the old, type-less version, while `@types/classnames` picked up the new stubbed version.
Removing `@types/classnames` and updating `classnames` to the latest version fixes the build error.
## Documentation / Examples
- [x] Make sure the linting passes
Adds a lint rule warning to the Next.js ESLint plugin if a custom Google Font is added at page-level instead of with a custom document (`.document.js`)
_Note: This will be generalized to include more font providers in the near future._
fixes a small bug which caused the webpack chunk to be too big as it includes references to all pages
## 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
- [ ] Make sure the linting passes
## 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
* fix check in externals that validate if the require is resolve-able for the server
* performance improvements
Fixes#23130
## 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.
- [x] 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.
## Documentation / Examples
- [ ] Make sure the linting passes
Closes https://github.com/vercel/next.js/issues/24889
## Feature
Currently `next build` is logging "Checking validity of types" even if `typescript.ignoreBuildErrors` is `true`. It seems like these options still work so `next build` either shouldn't log anything related to type-checking or log that type-checking is skipped.
I decided to branch the log message for clarity.
Happy to add a test but I'm not sure if you have existing infra considering https://github.com/vercel/next.js/pull/23226/files (which added the message) didn't add or change tests either.
CI failures look unrelated to me.
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 [official Sentry Next.js SDK](https://docs.sentry.io/platforms/javascript/guides/nextjs/) is now the recommended choice to use with Next.js, instead of the previous workarounds. This PR updates the example, which now uses the SDK.
..to use new zustand/context module from zustand 3.5.0. Also fixed code for merging states on client-side navigation.
## Documentation / Examples
- [x] Make sure the linting passes
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