This makes sure we properly resolve a rewrite when only the `href` value is used. This was causing a full-reload and was missed in the existing test since we weren't making sure a full navigation didn't occur which has been added in this PR.
Fixes: https://github.com/vercel/next.js/issues/16974
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`.
---
This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties.
There are two main assumptions here:
1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization.
2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported.
The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place!
That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet.
Fixes#11012Closes#16707
---
cc @Timer @timneutkens
This makes sure to strip the trailing slash before attempting to resolve the `href` against pages/dynamic routes and adds tests ensuring the correct pages are resolved with `trailingSlash: true` enabled.
Fixes: https://github.com/vercel/next.js/issues/16872
This makes sure we only pass the as value's `pathname` instead of the full value so that we don't accidentally include `query` values while resolving the rewrites. This also adds tests to ensure the rewrites are resolved with the correct query values when only providing `href` and when manually mapping them with `href` and `as`
Fixes: https://github.com/vercel/next.js/issues/16825
This is a small change to the image post-processor logic. When it's looking for images to preload, it will now ignore SVGs, as these are rarely the relevant images for LCP.
This pull request replaces our client-side style transitions with `<style>` tags over async `<link rel=stylesheet>` tags. This should fix some edge cases users see with Chrome accidentally causing a FOUC.
This also removes the need to perform an async operation before starting the render, which should remove any perceivable navigation delay.
---
Fixes#16289
Handles:
- Next.js version
- next.config.js `env` key
- `NEXT_PUBLIC_` prefixed environment variables
- next.config.js keys that affect performance
Ideally we don't invalidate the whole cache when `NEXT_PUBLIC_` / `env` key variables change, but this is just to initially make the caching reliable, this behavior is similar to the current webpack 4 behavior, so it can only be improved 👍
When navigating from a non-shallow page to a page that was navigated to shallowly in history it causes incorrect page data to be shown since an incorrect shallow navigation is done. We can only maintain shallow routing when the current page was navigated to shallowly and the page being navigated to in history was also navigated to shallowly. Additional tests to ensure this behavior is working has also been added.
Closes: https://github.com/vercel/next.js/issues/7395
Closes: https://github.com/vercel/next.js/issues/14928
Fixes: https://github.com/vercel/next.js/issues/16028
This pull request correctly tracks render cancelation behavior. Prior to this PR, we'd have an unhandled rejection that left the app in a bad state and no routeChangeError event was fired.
---
Closes#16424Fixes#16445
This makes sure to also check if a dynamic route matched after resolving a rewrite on the client to match behavior on the server. It also adds tests for this behavior to ensure it is working properly.
Fixes: https://github.com/vercel/next.js/issues/16454
This fixes a client-side file not being transpiled correctly when rewrites are used. The cross browser tests have been updated to make sure there are rewrites so the related code is included and not dead-code eliminated'
Closes: https://github.com/vercel/next.js/issues/16440
We were accidentally allowing data requests to be rendered unconditionally. Instead, we should also check them against the staticPaths result and 404 when appropriate.
---
Fixes#15383
This fixes page checking failing due to the trailing slash being present which causes pages to proxied by a rewrite when they shouldn't be. This also adds additional tests to ensure rewriting to an external resource is working correctly with `trailingSlash: true`
Fixes: https://github.com/vercel/next.js/issues/15700
This corrects the basePath being required check for filesystem routes to not consider the public folder catch-all route since it always matches even if the public file isn't present and instead moves the basePath check inside of the public-folder catch-all. Tests already exist that catch this by adding a public folder to the existing `basepath` test suite
Fixes: https://github.com/vercel/next.js/issues/16332
Closes: https://github.com/vercel/next.js/pull/16350
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.
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.
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
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)
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
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
Replace `url.parse` and `url.resolve` logic with whatwg `URL`, Bring in a customized `format` function to handle the node url objects that can be passed to router methods. This eliminates the need for `url` (and thus `native-url`) in core. Looks like it shaves off about 2.5Kb, according to the `size-limits` integration tests.
This adds handling for custom-routes with `basePath` to automatically add the `basePath` for custom-routes `source` and `destination` unless `basePath: false` is set for the route.
Closes: https://github.com/vercel/next.js/issues/14782
Removed Option to enable `ReactProductionProfiling` from configuration and added a CLI switch for the same.
Users can now do `next build --profile` to enable react production profiling.
Also added a warning to notify users about the performance impact
Fixes: #14688
This adds additional checks against the routeKeys used to build the named regexes for dynamic routes to ensure they follow PCRE rules for named capture groups
x-ref: https://github.com/vercel/vercel/pull/4813
Discovered while working on https://github.com/vercel/next.js/pull/14848
when asPath is the same but href is different it should use `replaceState` instead of `pushState`, so that browser back/forward behavior is preserved. Currently it's comparing a path that includes basepath with one that excludes it, so `pushState` is always used. This makes sure the behavior is the same as when running next.js without a basepath
This updates the scroll position saving to occur as the scroll position changes instead of trying to do it when the navigation is changing since the `popState` event doesn't allow us to update the leaving history state once the `popState` has occurred.
The order of events that was previously attempted to save scroll position on a `popState` event (back/forward navigation)
1. history.state is already updated with state from `popState`
2. we replace state with the currently rendered page adding scroll info
3. we replace state again with the `popState` event state overriding scroll info
Using this approach the above event order is no longer in conflict since we don't attempt to populate the state with scroll position while it's leaving the state and instead do it while it is still the active state in history
This approach resembles existing solutions:
https://www.npmjs.com/package/scroll-behaviorhttps://twitter.com/ryanflorence/status/1029121580855488512
Fixes: https://github.com/vercel/next.js/issues/13990Fixes: #12530
x-ref: https://github.com/vercel/next.js/pull/14075
Fixes: #13512
Defined and exported type for `metric` used in [reportWebVitals](https://nextjs.org/docs/advanced-features/measuring-performance)
```
export function reportWebVitals(metric) {
if (metric.label === 'custom') {
console.log(metric) // The metric object ({ id, name, startTime, value, label }) is logged to the console
}
}
```
One can now do
```
import { NextWebVitalsMetric } from 'next/app'
export function reportWebVitals(metric: NextWebVitalsMetric ) {
if (metric.label === 'custom') {
console.log(metric) // The metric object ({ id, name, startTime, value, label }) is logged to the console
}
}
```
Since the no-op rewrite is a valid rewrite used to check pages/assets before adding a 404-rewrite this makes sure we don't show the rewriting to auto-export dynamic pages warning from it
Closes: https://github.com/vercel/next.js/issues/14736
* avoid pulling code in the bundle for `trailingSlash` logic when it's not enabled
* avoid cloning the url an extra time if normalizing the path doesn't change it
Avoid trailing slashes on urls that look like files. The redirect for `trailingSlash: true` will now look like:
```
Redirects
┌ source: /:path*/:file.:ext/
├ destination: /:path*/:file.:ext
└ permanent: true
┌ source: /:path*/:notfile([^/.]+)
├ destination: /:path*/:notfile/
└ permanent: true
```
The default still looks like:
```
Redirects
┌ source: /:path+/
├ destination: /:path+
└ permanent: true
```
After this gets merged, I have a few optimizations planned on the normalization code that should reduce the client bundle a little and that consolidates the `trailingSlash` and `exportTrailingSlash` options
This updates `fetchNextData` to re-use the `getDataHref` function from `page-loader` which has more verbose handling to ensure the correct `/_next/data` URL is built. Re-using this logic ensures the `/_next/data` URL can still be built even when a mismatching `href` and `as` value is provided to `next/link`.
This also fixes a case in `getDataHref` where optional values that weren't provided would fail to build the data href since the check requiring the param be present while interpolating the route values hasn't been updated to allow missing params for optional values.
An additional test case has been added to the prerender suite to ensure the `/_next/data` URL is built correctly when mismatching `href` and `as` values are provided
x-ref: https://github.com/vercel/next.js/discussions/14536
x-ref: https://github.com/vercel/next.js/discussions/9081#discussioncomment-31160
Closes: https://github.com/vercel/next.js/issues/14668
Add tests and fix for when the url contains query parameters.
`router` now uses the same method for formatting url+as pair as `Link`, will be able to share code after https://github.com/vercel/next.js/pull/14633 is merged
We've been meaning to change this code for a while 👍
- Changed the name from spr to incremental
- Changed the code to be a class instead of using module scope variables
Closes [13709](https://github.com/vercel/next.js/issues/13709).
The solution works, **(tested and confirmed with true and false flags with the latest next version)** though I am quite sure this is not the most elegant and proper way to implement it. I have spent the good part of yesterday and today's morning in order to make it more generic but since it's my first time working with anything related to webpack I have struggled miserably. Last, but not least I'm unsure if this is the most proper naming for the flag.
Please, let me know what you want me to change and I'll get it done asap.
* Avoid adding basePath when it's not needed
When using the `basePath` setting, on pages with params it will fire a router change. This will pass the url pathname in the `as` param using the `getUrl()` function. This means the `as` path will be sent through already including the `basePath`, leading to `/basePath/basePath/path` which will cause the router to throw an error.
* lint
* Add test case and ensure removal
* Make sure to re-add before changeState
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Noticed this while reviewing https://github.com/vercel/next.js/pull/14376. After having done https://github.com/vercel/next.js/pull/13699, this code didn't feel right to me:
```js
function prepareRoute(path: string) {
path = delBasePath(path || '')
// this /index rewrite is problematic, it makes pages/index.js
// and pages/index/index.js point to the same thing:
return toRoute(!path || path === '/' ? '/index' : path)
}
```
Added a nested index page to the prerender tests and found it was rendering the `/` route on navigation. This uncovered 2 more places around the dataroute where the index path was not translated correctly.
**edit:**
Just to note that there was nothing wrong with https://github.com/vercel/next.js/pull/14376, the issue was already there, I just noticed it while reading that PR
Noticed while working on https://github.com/vercel/next.js/pull/14400 that the optional catch-all handling was missing in `namedRegex`.
This whole file also seemed quite regex heavy so I took a look at the overall logic and changed a few things. It worked by regex escaping the whole route then unescape the dynamic parts. I changed it to only regex escape the static parts, this eliminates unnecessary back and forth escaping. It also makes the dynamic parts handling more readable. The whole logic is less reliant on regexes and just uses simple string manipulation to translate the route into a regex, I didn't measure anything but as an effect this should make it more performant.
Updates the way filenames are generated for browser compilation.
Notably:
- All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path)
- The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals)
- All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals)
- In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals)
- Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals)
Follow up of these PRs:
https://github.com/vercel/next.js/pull/13759https://github.com/vercel/next.js/pull/13870https://github.com/vercel/next.js/pull/13937https://github.com/vercel/next.js/pull/14130https://github.com/vercel/next.js/pull/14176https://github.com/vercel/next.js/pull/14268Fixes#6303Fixes#12087Fixes#1948Fixes#4368Fixes#4255Fixes#2548
This corrects the `/_next/data` path generated when using `basePath` with `getStaticProps` in a `pages/index.js` file which was previously stripping the `basePath` without checking if `/index` needed to be appended after stripping. This also adds additional checks to the `basePath` test suite to prevent regressing
x-ref: https://github.com/vercel/next.js/pull/9872#issuecomment-646841260
This updates the named regexes output in the `routes-manifest` and the associated `routeKeys` to not use any non-word characters as this breaks the named regexes e.g. `"Invalid regular expression: "^/(?<data\-provider\-id>[^/]+?)(?:/)?$"`
x-ref: https://github.com/zeit/now/pull/4355
To make `asPath` consistent with `basePath` handling this makes sure it is always stripped including on the client under the `asPath` value and from `req.url` in the `serverless-loader`. Additional tests have been added for this behavior to ensure we don't regress on this
Closes: https://github.com/vercel/next.js/issues/14037
Closes: https://github.com/vercel/next.js/issues/14039
This correctly strips the `basePath` before generating the `route-matcher` for dynamic routes and adds regression tests to ensure these work correctly with the `basePath` feature
Closes: https://github.com/vercel/next.js/issues/13966
This adds scroll restoration handling to make sure the correct scroll position is restored after navigating back/forward to a page and the rendering hasn't completed by the time the default browser scroll restoration has taken place.
An initial failing test case was added which is working with the changes in this PR, if there are any other cases that should be added let me know and I can make sure we have them to ensure we don't regress on this behavior
---
Fixes#12530
Extracted from https://github.com/vercel/next.js/pull/13333, the same exact code lives in that PR as well, but we can merge this separately if it makes reviewing https://github.com/vercel/next.js/pull/13333 easier
This PR does 3 things
- deduplicate code from build and next-dev-server that loads custom routes from next.config.js (`loadCustomRoutes`)
- in `loadCustomRoutes`, load these rewrites, headers and redirects configs concurrently instead of sequentially.
- in next-server, make `this.customRoutes` always defined, this allows us to remove the big `if` around its initialization code in `generateRoutes`, which in turn makes it possible to reuse this code for other routing than user defined routes, which is how https://github.com/vercel/next.js/pull/13333 adds its redirects.
Initial work to use chunkhashes instead of buildid for the page files in production. This does not change the calculation of the filename itself initially.
As discussed, this streamlines the handling for `basePath` to not automatically strip and add the `basePath` when provided to `next/link` or `router.push/replace` and only automatically adds the `basePath` and when it is manually provided it will cause a 404 which ensures `href` still matches to the pages directory 1-to-1.
This also adds additional test cases that we discussed to ensure this behavior is working as intended
---
Fixes#13902
So I can't *entirely* explain why, but I believe this fixes#13132. 🙈 I basically ended up looking around at other `_next` URLs (are those asset URLs?) around the project and seeing that they tended to use `delBasePath()` to remove the base path from the current page's path whenever it was used.
When testing locally with the [repo submitted with the issue](https://github.com/robertovg/next-base-path-example), I no longer experience the constant page-reloading in dev mode when adding a query string to the URL.
This error isn't specific to just fallback SSG pages since any dynamic SSG page that is rewritten to can cause the `/_next/data` request to fail also since it currently derived from the the URL.
This can also fail for `getServerSideProps` since it derives the `/_next/data` URL the same way so might need to be updated to show in that case also
Disambiguate between pages/index.js and pages/index/index.js so that they resolve differently.
It all started with a bug in pagesmanifest that propagated throughout the codebase. After fixing pagesmanifest I was able to remove a few hacks here and there and more logic is shared now. especially the logic that resolves an entrypoint back into a route path. To sum up what happened:
- `getRouteFromEntrypoint` is the inverse operation of `getPageFile` that's under `pages/_document.tsx`
- `denormalizePagePath` is the inverse operation of `normalizePagePath`.
Everything is refactored in terms of these operations, that makes their behavior uniform and easier to update/patch in a central place. Before there were subtle differences between those that made `index/index.js` hard to handle.
Some potential follow up on this PR:
- [`hot-reloader`](https://github.com/vercel/next.js/pull/13699/files#diff-6161346d2c5f4b7abc87059d8768c44bR207) still has one place that does very similar behavior to `getRouteFromEntrypoint`. It can probably be rewritten in terms of `getRouteFromEntrypoint`.
- There are a few places where `denormalizePagePath(normalizePagePath(...))` is happening. This is a sign that `normalizePagePath` is doing some validation that is independent of its rewriting logic. That should probably be factored out in its own function. after that I should probably investigate whether `normalizePagePath` is even still needed at all.
- a lot of code is doing `.replace(/\\/g, '')`. If wanted, that could be replaced with `normalizePathSep`.
- It looks to me like some logic that's spread across the project can be centralized in 4 functions
- `getRouteFromEntrypoint` (part of this PR)
- its inverse `getEntrypointFromRoute` (already exists in `_document.tsx` as `getPageFile`)
- `getRouteFromPageFile`
- its inverse `getPageFileFromRoute` (already exists as `findPageFile ` in `server/lib/find-page-file.ts`)
It could be beneficial to structure the code to keep these fuctionalities close together and name them similarly.
- revise `index.amp` handling in pagesmanifest. I left it alone in this PR to keep it scoped, but it may be broken wrt nested index files as well. It might even make sense to reshape the pagesmanifest altogether to handle html/json/amp/... better
In serverless mode, it's best practice to propagate an unhandled error so that the function is disposed instead of recycled. This helps fix the "bad state" problem.
Was going through _document and noticed some variable shadowing going on. Added a rule for it to our eslint configuration and went through all warnings with @Timer.
Fixes https://github.com/vercel/next.js/issues/13524
To do:
- [x] fix dev mode
- [x] there's a ~route ordering or~ trailing slash issue with top level catch-all (current tests reflect that)
- [x] in this test `/get-static-paths/whatever` should fall back to `/[[...optionalName]].js` since `fallback` is `false` in its `getStaticPaths` method. ~Currently seems to 500~ must have been a glitch
- [x] add tests for `null`, `undefined` ~and `false`~ behavior as well (if decided these are valid)
- [x] ~add tests for string params as well~ this is not allowed for catch-all routes
- [x] test behavior when fallback is enabled and a top level catch-all exists
This addresses some errors for `/_next/data` requests where encoded `/` values in dynamic route param would cause invalid behavior, a headers already sent error would be shown when sending the fallback page in development, and when rendering the `_error` page for a data request the error response would still be treated as a data request.
This also adds test cases for these errors to prevent regression
Closes#12045
This PR adds support for [etags](https://tools.ietf.org/html/rfc7232#section-3.2) to Next.js' API routes, which will improve user experience and decrease network traffic by enabling usage of etag-based caching.
Since non-fallback pages don't rely on the URL for hydration we can allow them to be rewritten to but pages with fallback still can't be rewritten to because we won't be able to parse the correct `/_next/data` path to request the page's data from. I added a test for this behavior and ensured it works correctly on Now.
Example on with fallback false rewrite on Now:
https://tst-rewrite-cp9vge4bg.now.sh/about
This waits for the render to be committed to DOM before we render the route change complete event (no longer sync in new React).
We have tests that ensure this resolves.
---
Closes#12938
It seems like this was supposed to use the memoized version of `pageChecker`. I also updated the function to memoize promises instead of promise results. Just in case this function ever gets called concurrently.
* Generate sourcemaps for core files that pass through Babel
* Run files through Babel instead of tsc
* Get rid of wildcard helper
* Get rid of wildcard helper
* Remove unused file
* Update wildcard imports
* Add exclude
* Get rid of object-assign helper
* Use Object.assign as it gives better output
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add flag to disable API warning
This flag is useful when you are using an external API resolver like express when defining an API route, since the native functionality doesn't realize that the API actually sent a response.
A very simple use case example https://github.com/PabloSzx/next-external-api-resolver-examplefixes#10589
* Update api-middlewares.md
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
* Fix type on NextApiHandler
The example [here](https://nextjs.org/docs/api-routes/api-middlewares) shows that `NextApiHandler` can be async, so the return type should be `void | Promise<void>`.
* Add TS integration tests for API
This allows a page to be fully static (no runtime JavaScript) on a per-page basis.
The initial implementation does not disable JS in development mode as we need to figure out a way to inject CSS from CSS imports / CSS modules without executing the component JS. This restriction is somewhat similar to https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascript/. All things considered that plugin only has a usage of 600 downloads per week though, hence why I've made this option unstable/experimental initially as I'd like to see adoption patterns for it first.
Having a built-in way to do this makes sense however as the people that do want to adopt this pattern are overriding Next.js internals currently and that'll break between versions.
Related issue: #5054 - Not adding `fixes` right now as this implementation needs more work. If anyone wants to work on this feel free to reach out on https://twitter.com/timneutkens
* Add support for params in header key/values
* Update todo
* Update with handling for named patterns
* Use compiled package
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add basePath in link component and add/remove it consistently
* Update to not use regex for delBasePath
* Expose addBasePath as router method
* Revert "Expose addBasePath as router method"
This reverts commit 40fed596195c6affabf837e42d472452768e13a3.
* Expose basePath as router field
* Apply suggestion
* Expose basePath as router field
* remove un-used vars
* Update externals
* Apply lint fix
* Update size-limit test
* Update prefetch
* Add error/warning when a page is rendered without a /
Throws an error for development and gives a warning in production
* Add tests for error when rendering without starting slash
* Update to always warn and add err.sh
* Update errors/render-no-starting-slash.md
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
* Warn when user has pages/_error but no pages/404
* Update test
* Update custom-error-no-custom-404.md
* Apply suggestions from code review
Co-Authored-By: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
* Rename unstable GSP revalidate field
* Update error message
* Tweak error message some more
* Apply suggestions from code review
Co-Authored-By: Joe Haddad <joe.haddad@zeit.co>
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add initial support for new env config file
* Fix serverless processEnv call when no env is provided
* Add missing await for test method
* Update env config to .env.json and add dotenv loading
* ncc dotenv package
* Update type
* Update with new discussed behavior removing .env.json
* Update hot-reloader createEntrypoints
* Make sure .env is loaded before next.config.js
* Add tests for all separate .env files
* Remove comments
* Add override tests
* Add test for overriding env vars based on local environment
* Add support for .env.test
* Apply suggestions from code review
Co-Authored-By: Joe Haddad <joe.haddad@zeit.co>
* Use chalk for env loaded message
* Remove constant as it’s not needed
* Update test
* Update errsh, taskr, and CNA template ignores
* Make sure to only consider undefined missing
* Remove old .env ignore
* Update to not populate process.env with loaded env
* Add experimental flag and add loading of global env values
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add support for tsconfig/json `paths` option
* Add tests for paths in tsconfig.json
* Don't apply aliases when paths is empty
* Clean up unused methods and link to TypeScript license
* Add tests for jsconfig
* Put feature under an experimental flag
* Enable to see if tests pass
* Update types
* Add feature under an experimental flag
* Add support for SCSS includePaths
* Support sassOptions instead of just includePaths
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Make sure to not show pages/404 GIP error from _app having GIP
* Add error for getStaticProps in pages/404 too
* Add support for getStaticProps in pages/404
* Update test
* Verify GS(S)P Serializability
* Add support for cyclic refs
* Add unit tests
* Test for error in development mode
* Fix prerender preview tests
* Fix gssp preview tests
* fix 2x test cases
* Add desired test
* fix some more tests
* Fix route manifest expect
* Fix test expects
* Test that `getServerSideProps` does not error in production
* Test that getStaticProps is not checked in production
* Test serialization check during build
* Fix export detection for serverless
* Update test/unit/is-serializable-props.test.js
Co-Authored-By: JJ Kasper <jj@jjsweb.site>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Rename getServerProps to getServerSideProps
* Remove unstable_ prefix from new methods
* Add error when legacy methods are detected
* Add legacy methods for babel transform
* Add unstable_getServerSideProps also
* Apply suggestions from code review
Co-Authored-By: Joe Haddad <joe.haddad@zeit.co>
* Update types import
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Ability to Disable SSG Fallback
* Throw error when value is missing
* Fix existing tests
* Adjust error message
* Do not render fallback at build time for `fallback: false` page
* Fix existing fallback behavior
* fix build
* fix version
* fix some tests
* Fix last test
* Add docs for get static paths
* Add explicit mode tests
* test for fallback error message
* Make sure to show error when url prop is returned for a page
* Update test and handle undefined pageProps
* Handle empty props
* Apply suggestions from code review
Co-Authored-By: Tim Neutkens <tim@timneutkens.nl>
* Update tests
* Update to not add url prop for SSG/SSP pages
* Update errsh for reserved prop
* Update errsh wording some more
* Update tests and to warn instead of error
* Update reserved prop warning
* Include page in url prop warning
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Add calling getStaticPaths in development before showing fallback
* Move staticPathsWorker to next-dev-server
* Make sure to clear require cache in worker process
* bump
* Remove staticPathsCache member
* Update numWorkers for staticPathsWorker
* Add error messages for dynamic SSG page without getStaticPaths
* Update error check
* Update test file
* Update another test file
* Adjust
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Clean up landed experimental flags
* Remove check for experimental flags from build too
* Remove /_errors/404 in favor of /404
* Remove unneeded check for pathname
* Update test paths
* Fix test
* Update test
* Remove test for disabled config
* Set pages404 always to true
Co-authored-by: Joe Haddad <timer150@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Fixed pathname check in router
Remove the query portion of the URL when checking paths
* Updated change and added trial test
* Update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Remove ts-ignore where possible
And replace by typecasts
* More accurate types
* bend cliententries in a correct shape earlier on
* comment becomes unnecessary
* add webpack overload to allow for the next.js use case
* Avoid changing public interface
Co-authored-by: Joe Haddad <timer150@gmail.com>
This adds a `isFallback` property to detect if the page is being rendered in "fallback" mode or normal mode.
Accessed via the `useRouter()` hook.
---
Closes#10527
* Adjust SSG Loading Behavior
* Update expected preview behavior
* Rename two corrections
* Only use skeleton in production for now
* Fix "should SSR SPR page correctly" test
* fix tests
* fix trailing comment letter
* disable test for now
* checkpoint: api impl
* Add support for tryGetPreviewData
* snapshot: server(less) support
* Add X-Prerender-Bypass-Mode header support
* Pass preview data to getStaticProps call
* add TODO
* setPreviewData
* 100k iterations
* Handle jwt error
* Write out preview values
* forgot file
* set preview props
* Send preview props
* add preview props
* Pass around more data
* update yarn lock
* Fail on Invalid Prerender Manifest
* Make Missing Prerender Manifest Fatal
* fix ts errors
* fix test
* Fix setting cookies + maxage
* Secure is not needed as we encrypt necessary data
* Set on domain root
* Set cookie max ages
* Render a fallback on-demand for non-dynamic pages
* Test preview mode
* remove old build
* remove snapshots
* Add serverless tests
* use afterAll
* Remove object assigns
* fix cookie spread
* add comment
* Update next-server routes order for expected priority
* Update router to allow disabling page routes
* Fix headers having check: true behavior when they should not
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Add initial SSG fallback handling
* Remove extra changes and update fallback handling
* Remove extra timeout for testing
* Update SSG tests in dynamic-routing suite
* Add racing to decide between rendering fallback and data
* Update size-limit test
* Update comment
* Make sure to follow correct route change order
* Make comment more verbose for racing
* Revert getStaticData to only return Promise
* Make sure to update URL on fallback
* Add retrying for data, de-dupe initial fallback request, and merge fallback replace
* Update to add preload for fallback pages data
* Add test for data preload link
* Use pre-built fallback in production mode
* Remove preload link for fallback from _document
* Update to make sure fallback is rendered correctly for serverless
* Update to use existing util to de-dupe path check
* Update error message for requested/resolved mismatch
* Use correct dataRoute value for prerender manifest
* Fix pageUrl having double slash on Windows
* Add support for rewriting to external resources
* Update rewrite proxying test
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Implement experimental pages/404.js for custom 404 page
* Make sure to show error for getInitialProps in pages/404 in dev mode also
* Update routes-manifest tests for new value
* Make sure page404 is boolean in routes-manifest
* Rename variables for consistency
* Make sure to only use 404 page for 404 error
* fix: 9919 no exported config found
* fix: 9919 remove isolated test, add integration
* fix: 9919 add check for successfull compilation and fix warnin check
* Add test for development output
* fix: 9919 add error page and link to it in warning
* Update empty-configuration.md
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
* Add support for unstable_getServerProps
* Apply suggestions from review
* Add no-cache header and update types
* Revert sharing of load-components type
* Add catchall test and update routes-manifest field
* Update header check
* Update to pass query for getServerProps data requests
* Update to not cache getServerProps requests
* Rename server side props identifier
* Update to nest props for getServerProps
* Add no-cache header in serverless-loader also
* Update to throw error for mixed SSG/serverProps earlier
* Add comment explaining params chosing in serverless-loader
* Update invalidKeysMsg to return a string and inline throwing
* Inline throwing mixed SSG/serverProps error
* Update setting cache header in serverless-loader
* Add separate getServerData method in router
* Update checkIsSSG -> isDataIdentifier
* Refactor router getData back to ternary
* Apply suggestions to build/index.ts
* drop return
* De-dupe extra escape regex
* Add param test
* Allow mismatch href and as when manually provided
* Swap warning and error and throw error in production also
* Add test for mismatch error in production
* Update to only show warning in development
* added option to changeState when onlyAHashChange
* added integration tests
* segregated tests because they caused other tests to fail
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Support unnamed parameters in custom-routes correctly
* Update unnamed params checking to be strict
* Removed un-used regexKeys
* Update test routes
Co-authored-by: Joe Haddad <timer150@gmail.com>