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.
I noticed a problem with the example - when you leave it logged in for more than an hour it breaks. The example API call starts to fail with `auth/id-token-expired`.
Looking at the code I saw that we never update the id token after signing in, but firebase automatically updates it every hour, meaning our `verifyIdToken` fails after an hour.
So I used the `onIdTokenChanged` function from firebase to update the cookie every time the id token changes.
I'm open to suggestions on refactoring the code I've added.
## Motivation
As Graphcool is being shutdown, we replaced all the graphcool api endpoints with some handcrafted APIs using Prisma & Nexus, that can be found here https://github.com/prisma-labs/nextjs-graphql-api-examples. These GraphQL endpoints are now deployed to Vercel.
## Notes
- I couldn't get the reason-relay example to run. Given that the relay endpoint works on the other relay example, I don't see any reason why it wouldn't work on that one
- The `with-apollo` example is buggy when creating some posts, but nothing related to the switch of the api endpoint as it was already buggy before. I suspect the `concatPagination` strategy to be the cause of that bug, but I couldn't figure it out.
Fixes#14780
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
Remove the dotenv dependency from all examples (in favor of environment support): #15225
All variables are exposed to the client. This Example does not use firebase-admin.
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
I was referencing the with-passport example and found a minor syntax error:\
The login and signup page both used `event.preventDefault()` on the submit handlers, whereby the correct reference to the event is `e` as defined within the `handleSubmit` functions.
Additionally used the chance to bump npm packages, the largest bump being swr to the latest version: 0.3.0
### Summary of all Changes made:
* Fixed syntax error on login page
* Fixed syntax error on signup page
* Bumped cookie to 0.4.1
* Bumped next-connect to 0.8.1
* Bumped swr to 0.3.0
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)
Following up from #14830, this PR adds a new page to the docs for Create Next App. The content is identical to the README created as part of #14830.
Also added a link on the main `getting-started` page to the new docs for Create Next App to help users find more info on Create Next App if needed.
I'm unsure as to whether the content for the documentation needs to be different from the one I wrote for the README. Please let me know if that's the case, and I will be happy to tweak the structure.
- 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
While it is mentioned in the [link documentation](https://nextjs.org/docs/api-reference/next/link), I think it is useful to also explain in the dynamic route documentation that you need to include the as parameter when routing to a dynamic route/
