Fixes#24056.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] 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 expands on https://github.com/vercel/next.js/issues/24070 and ensures we show the dev overlay for additional cases like where `_app` or `_document` have syntax errors causing compilation to not be able to complete. This achieves showing the dev overlay even when compilation fails from a syntax error by doing a third minimal compilation in development with the needed client-side assets to render the dev overlay.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
x-ref: https://github.com/vercel/next.js/issues/24070
This pull request **temporarily** removes ESLint, as it was not landed in accordance with our standard experimental policies. We are fully committed to landing this change again.
This is being reverted because:
- Next.js has very strict goals for its install size. This feature resulted in adding over 17MB, or a 43.6% increase.
- The feature was not first landed under the `experimental` key in `next.config.js`, rather, it was added under the stable namespace (top-level)
- Using the feature doesn't do a "guided setup" like TypeScript, it should ask you to "bring your own" dependencies for ESLint
- It uses a undesirable ESLint plugin name: `plugin:@next/next/recommended`. This should read out as strictly `next`, or as short as we can get it.
- Does not provide actionable warnings (missing link to resolve issue)
- Does not follow appropriate console output styling. We need to revisit how these are presented.
To re-land this, we need to ensure the following minimums are met:
- Very minor change in install size
- Fully experimental (i.e. flagged) with warnings
- Finalized package name and configuration shape, preferably so we can do ` { extends: 'next' } `.
This adds support for returning an object from `rewrites` in `next.config.js` with `beforeFiles`, `afterFiles`, and `fallback` to allow specifying rewrites at different stages of routing. The existing support for returning an array for rewrites is still supported and behaves the same way. The documentation has been updated to include information on these new stages that can be rewritten and removes the outdated note of rewrites not being able to override pages.
## 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`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
For #22228
This PR:
- Adds ESLint to toolchain
- Included by default for builds (`next build`)
- Can be enabled for development (`next dev`)
- Custom formatter built for output
- Adds appropriate tests
- Adds two documentation pages
Prior to this pull request, Next.js would immediately decode all URLs sent to its server (via `path-match`).
This was rarely needed, and Next.js would typically re-encode the incoming request right away (see all the `encodeURIComponent`s removed in PR diff). This adds unnecessary performance overhead.
Long term, this will also help prevent weird encoding edge-cases like #10004, #10022, #11371, et al.
---
No new tests are necessary for this change because we've extensively tested these edge cases with existing tests.
One test was updated to reflect that we skip decoding in a 404 scenario.
Let's see if all the existing tests pass!
This makes sure to the page path is the expected version to trigger refreshing on the client and adds additional tests to make sure it is working properly with these page variants.
Closes: https://github.com/vercel/next.js/issues/16938
This adds initial support for reloading the page when `getStaticProps`, `getStaticPaths`, or `getServerSideProps` were changed for a page by triggering a reload when the server output for a page has changed but the client output has not since these methods aren't included in the client output.
Closes: https://github.com/vercel/next.js/issues/13949
- 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
Chunks already have a normalized path.
Not sure if there are other chunks that require this change, I did a global search and didn't find similar cases.
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
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
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.
This code existed mostly to work around webpack 2 (yes 2.x) limitations where it crashed in certain cases where files didn't exist anymore. We have tests for that behavior and latest webpack has fixed these. Hence why this can be removed 👍
As discussed this adds bundling of `.env` files in `serverless` mode so that the environment values are also available when deploying with this target
closes: https://github.com/zeit/next.js/issues/13332
* 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
