This fixes an edge case where every dozen or so transitions you'll see a flash depending on what's happening on the main thread at the time.
I'm not sure it's possible to test for this case, so we'll just have to do more field testing with this.
This PR replaces `prop-types-exact` (only used in this location) with manual property checking.
Right now, malformed properties sent to `<Link>` are silently handled and only emit a warning in the console.
This leads to confusing/unexpected errors because we try to read a value that is undefined.
To fix this, we'll now throw a proper error when `<Link>` is misused. **This still isn't optimal, however, because we don't have a component stack trace we can give the user**.
We're not going to be able to give the user actionable instructions until React 16.14 at a minimum.
---
Fixes#13951Fixes#16107Closes#13962
Don't use this yet as it's still being developed. This is a first iteration that enables the webpack cache. There's still more to do here, for example if css modules are used there's currently a bug where webpack does not save the cache for browser compilation (impacting build performance). @sokra is going to look into that issue.
This pull request adds a test case for the reproduction provided in #12445. This bug is specifically caused when loading the next page before navigation has actually occurred.
---
Fixes#12445
This fixes the incorrect `/_next/data` URL being generated on client transition due to the `as` value passed to `getRouteInfo` having the `basePath` which is used while interpolating the values for dynamic routes, specifically root catch-all routes. A regression test has also been added to ensure this is working
Closes: https://github.com/vercel/next.js/issues/15747
This updates to not automatically append params to the query for rewrites if one or more of the params are already used in the destination's path. No other behavior is being changed and if the user still wants the params in the query after using them in the destination's path they can manually add them like with redirects.
Closes: https://github.com/vercel/next.js/issues/15626
This pull request edits the `BuildManifest` that is sent to `/_document` instead of modifying a single input array to decouple its implementation details.
Optimally, we'd eliminate the `files` key all together.
---
Related to #16182
This PR removes a legacy router method that was used for old-style HMR, now replaced by Fast Refresh.
This method was not public:
```tsx
export type NextRouter = BaseRouter &
Pick<
Router,
| 'push'
| 'replace'
| 'reload'
| 'back'
| 'prefetch'
| 'beforePopState'
| 'events'
| 'isFallback'
>
```
Even if someone found this method, it's highly unlikely they could use it successfully—it required the full module object.
In most browsers, clicking links with the Alt key has a special behavior, for example, Chrome downloads the target resource. As with other modifier keys, the router should stop the original navigation to avoid preventing the browser’s default behavior.
When users click a link while holding the Alt key together, the browsers behave as follows.
Windows 10:
| Browser | Behavior |
|:-----------|:--------------------------------------------|
| Chrome 84 | Download the target resource |
| Firefox 79 | Prevent navigation and therefore do nothing |
| Edge 84 | Download the target resource |
| IE 11 | No impact |
macOS Catalina:
| Browser | Behavior |
|:-----------|:--------------------------------------------|
| Chrome 84 | Download the target resource |
| Firefox 79 | Prevent navigation and therefore do nothing |
| Safari 13 | Download the target resource |
This adds the following Node.js core polyfills only when the import is used:
- `path`
- `stream`
- `vm`
- `crypto`
- `buffer`
Fixes#15948
We'll have a separate issue about adding warnings for the usage of these modules in the browser, some polyfills like crypto are quite heavy and generally not needed for most applications (included accidentally through node_modules).
Fixes#15928
---
This would cause us to print the message too early and open the browser to a server that wasn't started yet. This waits until we're listening, but before the app is ready fully.
Since we now use query parameters to pass dynamic route params while routing on Vercel, this makes sure we normalize the request URL before populating the `asPath`
Fixes: https://github.com/vercel/next.js/issues/15879
This PR adds a second experimental post-processing step for the framework introduced by @prateekbh in #14746. The image post-processing step scans the rendered document for the first few images and uses a simple heuristic to determine if the images should be automatically preloaded.
Analysis of quite a few production Next apps has shown that a lot of sites are taking a substantial hit to their [LCP](https://web.dev/lcp/) score because an image that's part of the "hero" element on the page is not preloaded and is getting downloaded with lower priority than the JavaScript bundles. This post-processor should automatically fix that for a lot of sites, without causing any real performance effects in cases where it fails to identify the hero image.
This feature is behind an experimental flag, and will be subject to quite a bit of experimentation and tweaking before it's ready to be made a default setting.
Next.js plugins like `@next/mdx` inject additional webpack loaders to compile files, but they omit the necessary loader for Fast Refresh to work.
Instead of making these files deopt out of Fast Refresh, we can automatically detect and inject the loader in these cases.
Fixes#13574
By popular request, this pull request adds support for returning `fallback: 'blocking'` from `getStaticPaths`.
This new mode will cause unknown paths to be rendered on-demand ("SSR") without the static (placeholder) fallback.
This feature is **currently experimental and should not be used in production yet**. It's currently flagged behind `unstable_`:
```
fallback: 'unstable_blocking'
```
TODO:
- [x] Next.js tests
- [ ] Add Vercel support
- [ ] Vercel tests
---
Fixes#15637
These changes aim to resolve most of the concerns raised in #15756. It adds missing polyfills for legacy browsers up until ES2019:
- Number.{parseFloat,parseInt}
- ~Math.{acosh,asinh,atanh,cbrt,clz32,cosh,expm1,fround,hypot,imul,log10p,log1p,log2,sign,sinh,tanh,trunc}~ _[Removed as these are [not widely used](https://github.com/vercel/next.js/pull/15772#discussion_r463957931)]_
- While these may seem to weigh a lot, they barely add 1 kB to the resulting bundle:
<img width="492" alt="gzip: 32 kB vs. 30.9 kB, Brotli: 28.8 kB vs. 27.8 kB" src="https://user-images.githubusercontent.com/14854048/89100961-1376e600-d3fc-11ea-90fd-3e6632b70220.png">
- ~Object.fromEntries~ _[Removed as [it's rarely used in user code](https://github.com/vercel/next.js/pull/15772#discussion_r463984612)]_
Also, the following features are now supported with build-time transforms:
- ~`globalThis` (gets transformed into `window` in browser environments)~ _[Removed as it [could break existing applications](https://github.com/vercel/next.js/pull/15772#discussion_r463956269)]_
- `export * as ns from 'module'`
The suggested TypeScript library version has been set to ES2018, so the features below become unavailable in type-checked files (they're not evenly supported by module-compatible browsers, either):
- Object.fromEntries
- String.prototype.matchAll
- String.prototype.replaceAll
- Promise.any + AggregateError
- WeakRef
As for the `import.meta` support, [webpack v5 seems to fix that](https://github.com/webpack/webpack/pull/11075), so it should eventually become an issue of the past.
---
Fixes#15756
In terms of url rewriting, `trailingSlash` supports everything `exportTrailingSlash` does. We can just share all other code paths and deprecate `exportTrailingSlash`.
This PR shows a deprecation warning when `exportTrailingSlash` is used.
Also fixes https://github.com/vercel/next.js/issues/15774
We can update the tests now or later. (I kept them the same to prove it's non-breaking)
To do:
- [x] Do we want to keep this? => nope 841d4efc51/packages/next/next-server/lib/router/router.ts (L329)
- [x] I kept `exportTrailingSlash` here. Do we want to rename that as well? => nope 2d9d649d49/packages/next/build/index.ts (L959)
- Use latest terser version (still 1 warning in the stable version which is an open PR)
- Add emitOnErrors instead of noEmitOnErrors
- Added trace-deprecations for Next.js core development
- Using `namedChunks` where possible, this will also allow for faster access to the chunks as we no longer have to look them up like we did before using `find`
- Using the new asset hooks introduced in the latest webpack beta
- Using the new externals function signature
I think this is necessary for IE11.
via [Webpack docs](https://webpack.js.org/migrate/5/#turn-off-es2015-syntax-in-runtime-code-if-necessary)
> By default, webpack's runtime code uses ES2015 syntax to build smaller bundles. If your build targets environments that don't support this syntax (like IE11), you'll need to set output.ecmaVersion: 5 to revert to ES5 syntax.
Thank you
`pageProps` should always be defined to ensure everything is working as expected although to prevent a breaking change this adds an additional check before attempting to access `pageProps` before hydration. It also adds tests to prevent regressing on this
Closes: https://github.com/vercel/next.js/issues/15647
This updates collecting dynamic route params on Vercel to make sure that missing optional dynamic routes are undefined. Additional tests for this mode have also been added to ensure the params are being collected properly
Closes: https://github.com/vercel/next.js/issues/15579
* More helpful README
Updated to include more details about Next.js, link to the interactive tutorial, showcase, etc. Content mostly based on the official Next.js site.
* create-next-app readme
An updated readme with more details on options, benefits, etc.
* Apply edits from code review
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
* Remove redundant intro
* Update packages/create-next-app/README.md
* Remove introduction and list in showcase
* Apply suggestions from code review
* Update packages/next/README.md
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Fixes https://github.com/vercel/next.js/issues/15188
`parseRelativeUrl` was used on urls that weren't always relative. It was used to generate a cache key, but we actually don't need these cache keys to be relative if the urls aren't relative.
Also took a look at the overall static data fetching logic and found a few things:
- [x] cache key is unnecessarily transformed through `prepareRoute`, we can just cache by resolved `dataHref` and remove that function. Pretty sure that `prepareRoute` was also introducing edge cases with `assetPath` and `delBasePath`
- [x] there is [a bug in the caching logic](ebdfa2e7a3/packages/next/next-server/lib/router/router.ts (L898)) that made it fail on the second visit: it should be `Promise.resolve(this.sdc[pathname])` instead of `Promise.resolve(this.sdc[dataHref])`. Also added a test for this
- [x] ~converted to async await to improve stacktraces and readability.~ I assumed this was fine since I saw some async/awaits in that file already but it seems to just blow up the size of the non-modern bundle.
- [x] extracted nested `getResponse` function and define it top level. this should improve runtime performance
- [x] convert `_getStaticData` and `_getServerData` to class methods instead of properties. Not sure why they were defined as properties but I think they belong on the prototype instead.
- [x] remove `cb` property from `fetchNextData`, it's unnecessary and makes the async flow hard to understand. The exact same logic can go in the `.then` instead.
- [ ] data fetching logic [retries on 5xx errors](ebdfa2e7a3/packages/next/next-server/lib/router/router.ts (L157)), but not on network level errors. It should also retry on those. It should also not retry on every 5xx, probably only makes sense on 502, 503 and 504. (e.g. 500 is a server error that I wouldn't expect to succeed on a retry)
The overall result also is a few bytes smaller in size
Next.js forcibly setting `module: 'esnext'` in `tsconfig.json` is necessary to prevent TypeScript from erroring on the following code:
```tsx
import dynamic from 'next/dynamic';
const A = dynamic(() => import('../A'));
```
```
ERROR in /Users/joe/Desktop/scratch/test-cjs/pages/index.tsx(5,25):
5:25 Dynamic imports are only supported when the '--module' flag is set to 'es2020', 'esnext', 'commonjs', 'amd', 'system', or 'umd'.
> 5 | const A = dynamic(() => import("../test"));
```
However, users may want to use one of the many other targets for better interoperability with projects that co-exist with their Next.js project (like `commonjs`).
When cross referenced with:
```
Option '--resolveJsonModule' can only be specified when module code generation is 'commonjs', 'amd', 'es2015' or 'esNext'.ts
```
That means we can permit any of these values:
```json5
parsedValues: [
ts.ModuleKind.ES2020,
ts.ModuleKind.ESNext,
ts.ModuleKind.CommonJS,
ts.ModuleKind.AMD,
],
```
This PR updates Next.js to allow those!
---
Fixes#15275
