@timneutkens it'd be great to get your input.
These changes introduce a new Babel loader that eliminates much of the existing overhead, resulting in better HMR speeds.
Multithreading is still in flight, and may be omitted if speed improvements end up being negligible. For now, the new loader is hidden behind an `experimental` flag.
Items to be completed before this PR is ready to merge:
- [x] reconfigure `ncc` to precompile the parts of `@babel/core` and `@babel/traverse` that we're accessing directly
- [x] change `@babel/core/...` imports to `ncc`ed version
- [x] ~~measure multithreading (not currently pushed) functionality, and include the functionality depending on the results~~ I'll open a separate PR for this
- [x] ensure TypeScript is happy with all imports as final step (`--no-verify` was used to bypass)
There will be two follow-up PRs:
- loader support for projects with custom `.babelrc`
- multithreaded loader (should the change we warranted after measurement)
This ensures we don't attempt prepending the `basePath` for external (http://) `getStaticProps`/`getServerSideProps` redirects. Additional tests to cover this case have been added in the `gssp-redirect` test suites to prevent regression.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23623
## 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
Fixes: #23716
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
Previously we special cased serverless builds and ran the client/server builds serially to allow the server build to load manifests produced in the client. To help with memory usage and for consistency this updates server mode to build in the same way.
## 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 adds support for a `has` field to `rewrites`, `redirects`, and `headers` to allow matching against `header`, `cookie`, and `query` values. Documentation and additional tests for the feature is also added in this PR.
Closes: https://github.com/vercel/next.js/issues/22345
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
Brings back the remaining Node.js module polyfills to not break existing apps upgrading from webpack 4 to webpack 5.
Fixes#23169
## 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
## 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
Fixes#23240
This PR attempts to provide an option to allow importing TS/TSX from outside of the current Next.js project root directory. Although this goes against the design decision that no source code should be imported from outside of root and [might bring tons of issues](https://github.com/vercel/next.js/issues/19928#issuecomment-741596557), it will still be helpful in some monorepo use cases.
This PR assumes that the external files are following the same language syntax rules and under the same tooling versions as the source code inside your project root. And it's also not allowed to enable the `baseUrl` feature in the external directory (as the project should only have 1 import base URL).
X-ref: #9474, #15569, #19928, #20374.
This allows to use `__NEXT_WEBPACK_LOGGING` to enable verbose webpack logging output to investigate into performance and cache problems.
`__NEXT_WEBPACK_LOGGING=1` enables some basic logging
`__NEXT_WEBPACK_LOGGING=infrastructure` enables only infrastructure logging
`__NEXT_WEBPACK_LOGGING=profile-client` enables deep profile output of the client build
`__NEXT_WEBPACK_LOGGING=profile-server` same for the server
`__NEXT_WEBPACK_LOGGING=profile-client,infrastructure` combines multiple things
* this will fix problems with serverless target which doesn't use a runtime chunk
* It also omit env vars from contributing to cache version as webpack will handle that now
* It moves the webpack-runtime chunk from ./chunks back to ./
This PR upgrades `jest-worker` and `jest-cli` to the latest pre-release version, also removed `jest-circus` which is included in Jest by default. `jest-worker@next` includes a fix for memory leak that we need (https://github.com/facebook/jest/pull/11187).
Fixes#22925. This will also improve the OOM issue for `next dev` #15855.
This makes sure we don't trigger the export step if we aren't exporting any static pages during a build. This also adds an invariant to ensure we don't attempt creating a progress with 0 items.
Fixes: https://github.com/vercel/next.js/issues/22994
A number of changes here. I recommend viewing the diff with the <a href="?w=1">whitespace flag enabled</a>.
- OpenTelemetry is replaced with a custom and lightweight tracing solution.
- Three trace targets are currently supported: console, Zipkin, and NextJS.
- Tracing is now governed by environment variables rather than `--require instrument.js`.
+ `TRACE_TARGET`: one of `CONSOLE`, `ZIPKIN`, or `TELEMETRY`; defaults to `TELEMETRY` if unset or invalid.
+ `TRACE_ID`: an 8-byte hex-encoded value used as the Zipkin trace ID; if not provided, this value will be randomly generated and passed down to subprocesses.
Other sundry:
- I'm missing something, probably a setup step, with the Zipkin target. Traces are captured successfully, but you have to manually enter the Trace ID in order to view the trace - it doesn't show up in queries.
- I'm generally unhappy with [this commit](235cedcb3e). It is... untidy to provide a telemetry object via `setGlobal`, but I don't have a ready alternative. Is `distDir` strictly required when creating a new Telemetry object? I didn't dig too deep here.
As noted, there are a lot of changes, so it'd be great if a reviewer could:
- [ ] pull down the branch and try to break it
- [ ] check the Zipkin traces and identify possible regressions in the functionality
Closes#22570Fixes#22574
This updates to not automatically export `/500` from `_error` if a custom `getInitialProps` is used since logic may be used inside of this method that causes the export to fail. Users can still opt-in to the static `/500` by adding a `pages/500.js` file.
This also refactors checking `_app` for custom `getInitialProps` to outside of the static check loop to prevent a potential race condition where we could run this check multiple times un-necessarily.
Fixes: https://github.com/vercel/next.js/issues/22815
This ensures we load `_document` then `_app` and then the page's component in all cases which matches behavior between the serverless target and the default server target. Additional tests to ensure this order is followed has been added to prevent regression.
Fixes: https://github.com/vercel/next.js/issues/22732
This updates to output server chunks to a nested folder to prevent bundling the entire folder when tracing. This also fixes the webpack 5 tests not actually using webpack 5 since https://github.com/vercel/next.js/pull/22583 since the webpack 5 enabling check didn't account for the test environment variable used to enable webpack 5. This also clears up some deprecation warnings from webpack 5 in the mini-css-extract-plugin.
Fixes: https://github.com/vercel/next.js/issues/21297
This pull request ensures the webpack hook is installed before an attempt is made to load the configuration.
This pull request is tested by the PnP tests, which should now be passing as a result of this change.
---
Fixes#21679
Fixes https://github.com/vercel/next.js/issues/21943
i confirmed in a personal test repo that this solves the issue of infinite 307s on root level non-default locales :) let me know what else this needs if anything! thanks for the time/help @ijjk ❤️
This adds generating a static 500 status page when a `pages/500.js` file is added similar to how we handle generating static 404 pages when `pages/404.js` is present. This allows showing a customized error page when a 500 error occurs in an optimal way.
This pull request removes the native `sharp` dependency (which doesn't work on some Linux variants, nor **M1 Mac**) and replaces it with a wasm equivalent.
It also reduces Next.js' installed size by 27.3 MB.
The code is adapted from the [Squoosh CLI](https://github.com/GoogleChromeLabs/squoosh).
This PR still supports:
- Rotation normalization
- Resizing
- PNG
- JPEG
- Webp
However, it (temporarily) removes support for:
- Resizing Gifs
- Resizing Tiff
(these formats still get served and rendered correctly by the image component)
---
Fixes#20456Closes#20738Closes#21762
This implements the compatibility require hook as per https://github.com/vercel/next.js/issues/21789.
The hook is applied at the point of webpack initialization. In addition the separate packages are exposed for the various webpack subrequires.
The test then ensures instance equality for the basic require hook from the next.js config file.
I suspect this might have bad interactions with Yarn Pnp support, but maybe we will be lucky.
@timneutkens I think this is ready for a review.
I've made some changes to the original design that _seem_ to have paid off. The parenting relationships for traces of normal builds are applied more uniformly, resulting in more intelligible traces:
<img width="900" alt="Screen Shot 2021-01-29 at 12 53 47 AM" src="https://user-images.githubusercontent.com/5016978/106253732-ba321880-61cc-11eb-98fd-d45af5078273.png">
Hot-reloading is surfaced now, too. I will note, however, that we will want to dig in deeper and find out where the large portion of time at the beginning of hot-reload is spent. Example:
<img width="894" alt="Screen Shot 2021-01-29 at 12 53 28 AM" src="https://user-images.githubusercontent.com/5016978/106253828-e057b880-61cc-11eb-967d-46eaff31ecef.png">
Where did those 180 ms go? At the least, we can now track how long a hot-reload takes, and have a place to start with further investigation.
This insures we add entries for each locale version of a non-dynamic SSG page since they can have unique revalidate values. This requires a version bump in the `prerender-manifest` since the static routes now contain additional values which need to be handled separately.
Fixes: https://github.com/vercel/next.js/issues/21568
This picks up on the inlining work in https://github.com/vercel/next.js/pull/20598 to also include webpack loader inlining optimizations.
This includes:
* The dependencies of sass-loader
* resolve-url-loader
And for added benefit:
* babel-plugin-transform-define
* babel-plugin-transform-react-remove-prop-types
style-loader and css-loader didn't inline easily. Perhaps we can come back to these ones.
This pull request adds `future.strictPostcssConfiguration`, allowing users to opt-into the more strict PostCSS configuration loading.
This stricter PostCSS configuration loading ensures that CSS can be cached across builds.
This updates the error shown when a path doesn't match the dynamic route in `getStaticPaths` to not include the `locale` since this isn't considered when matching against the dynamic route.
This PR fixes a bug where `next/babel` would accidentally enable development transforms for a production build (`next build`).
This is tested by the two updated unit tests (which removed a workaround for this bug, and one now properly enables dev transforms).
---
Fixes#18929Fixes#19001
x-ref #19046
x-ref #17032
This ensures we detect domain specific locales and redirect them client-side. Tests have been added in the `i18n` suite to ensure the domain redirect is applied correctly during a client-side navigation
Fixes: https://github.com/vercel/next.js/issues/19174
Fixes: https://github.com/vercel/next.js/issues/15278
> Bug report
> When using next dev with emacs, as you develop, emacs creates symbolic link files starting with .# as lock files. Next.js seems to attempt to load these but fails, spewing out errors constantly.
Prevents dev server from crashing when emacs creates lockfiles
tested with:
- GNU Emacs 27.1
- OSX 11.1
- Node v15.4.0
This removes `import type` usage from our core files since `import type` requires a higher TypeScript version than currently expected.
Fixes: https://github.com/vercel/next.js/issues/19300
This ensures the pages-manifest only includes forward slashes and not backslashes when adding i18n page references, this also adds tests ensuring we don't regress on this in the i18n-support test suite.
Fixes: https://github.com/vercel/next.js/issues/20330
There's currently two bugs with the font optimization, but we'd really like to ship a stable version.
To unblock the stable release, we're **temporarily** reflagging this. It'll be unflagged on canary again!
Solves the following warning:
> (node:1484) [DEP_WEBPACK_MAIN_TEMPLATE_REQUIRE_FN] DeprecationWarning: MainTemplate.requireFn is deprecated (use "__webpack_require__")
Nitpicky change, but the version string contained a double `|`, implying that there might be an empty value between `process.env.__NEXT_VERSION` and the environment variables.
* make the error message more clear if webpack config comes back undefined
* Update check and add test
* bump
* Update build-output test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This reverts #18921 and ensures that the Babel runtime is only inlined as an absolute path when using PnP as before, but then including the correction this resolution as implemented by @merceyz only in the PnP cases, while keeping the diff to a minimum.
This PR removes the modern mode experiment because:
- It does not yield meaningful bundle size wins when compared to other initiatives we've taken
- It's not compatible with webpack 5 (which we're upgrading to)
- It's currently broken and causes most apps to malfunction
- There's no champion currently owning the experiment
We can re-introduce this in the future when we'd like to make it a default for all Next.js apps.
Note: **Next.js still supports Differential Loading (`nomodule`) and does it by default.** This PR strictly removes the experimental modern _syntax_, and does not disable our existing modern/legacy polyfilling.
---
Fixes#19200Fixes#18960Fixes#14707Fixes#14465
We accidentally regressed back in 9.5 and dropped support for inline CSS comments. PostCSS always parses these as pass-through (and not a syntax error), which can cause problems when minifying.
Browsers do a similar thing and ignore the comments.
To ensure we generate valid CSS, this adds support for stripping the CSS comments from the build.
---
Fixes#15589Closes#17130
This ensures root optional-catch-all index routes with i18n are output to the correct location and are also loaded from the `prerender-manifest` correctly.
Fixes: https://github.com/vercel/next.js/issues/19095
This fixes a few things related to optional catch-all routes and i18n. The first thing is it ensures the correct data route is generated on the client so that the locale isn't duplicated for an optional catch-all route, the next is it ensures the browser history is updated correctly when only a locale change is occurring, and then it also ensures we handle the locales and normalizing for fallback optional catch-all pages correctly.
Tests have been added to ensure these cases are covered properly and we don't regress on them, these changes were also tested on Vercel [here](https://next-js-bug-i18n-root-params-nybg44l0b.vercel.app/)
Fixes: https://github.com/vercel/next.js/issues/18633
Fixes: https://github.com/vercel/next.js/issues/19059
This ensures we use the `defaultLocale` for a locale domain when rendering non-static pages. Static pages will initially contain the global `defaultLocale` and then be updated on the client since we don't currently prerender a version of the pages for each locale domain.
Closes: https://github.com/vercel/next.js/issues/18970
This upgrades to ncc@0.25.0 and fixes the previous bugs including:
* ncc not referenced correctly in build
* Babel type errors
* node-fetch, etag, chalk and raw-body dependencies not building with ncc - these have been "un-ncc'd" for now. As they are relatively small dependencies, this doesn't seem too much of an issue and we can follow up in the tracking ncc issue at https://github.com/vercel/ncc/issues/612.
* `yarn dev` issues
Took a lot of bisecting, but the overall diff isn't too bad here in the end.
This adds inlining for Babel and the Babel plugins used in next.
This is based to the PR at https://github.com/vercel/next.js/pull/18823.
The approach is to make one large bundle and then separate out the individual packages from that in order to avoid duplications.
In the first attempt the Babel bundle size was 10MB... using "resolutions" in the Yarn workspace to reduce the duplicated packages this was brought down to a 2.8MB bundle for Babel and all the used plugins which is exactly the expected file size here.
This will thus add a 2.8MB download size to the next package, but save downloading any babel dependencies separately, removing a large number of package dependencies from the overall install.
This is a prerequisite to being able to ncc inline the Babel dependencies in next.js.
The removal of preset-modules is based on replacing it with preset-env under `targets: { esmodules: true }`, as per the guidance from the package (https://www.npmjs.com/package/@babel/preset-modules):
> Starting from @babel/preset-env 7.9.0, you can enable the bugfixes: true option to get the same behavior as using @babel/preset-modules, but with support for custom targets. If you need to target browsers with native modules support (like this preset does), you can use targets: { esmodules: true }.
From the above, I'm pretty sure this is entirely a backwards compatible change, apart from the change to the runtime plugin list being visible. Perhaps @developit can confirm this as well.
When visiting a non-locale prefixed path (`/hello` instead of `/fr/hello`) we don't trigger locale redirects currently so if another locale is matched we need to ensure this is reset to the `defaultLocale` for rendering to prevent a mis-match on the client and the server.
This also fixes hydration errors from occurring with `asPath` for `getServerSideProps` pages due to `normalizeLocalePath` expecting only a pathname and `asPath` containing `hash` and `query values also.
Fixes: https://github.com/vercel/next.js/issues/18337
Fixes: https://github.com/vercel/next.js/issues/18510
This makes sure we don't use invalid `x-now-route-matches` which can occur when `i18n` default locale is visited and a prerendered page is matched. To correct this we first check if we are able to derive the correct params from the URL and then bail on parsing `x-now-route-matches` if we are. Additional test cases are being added in the builder to ensure we don't regress on this
x-ref: https://github.com/vercel/next.js/discussions/18443Fixes#18602
This ensures we provide the current `locale`, `locales`, and `defaultLocale` in the context when rendering the 404 for a blocking SSG page
Fixes: https://github.com/vercel/next.js/issues/18505
This ensures that when using a `pages/404` file with `getStaticProps` that we call `getStaticProps` in `fallback: 'blocking'` mode
Fixes: https://github.com/vercel/next.js/issues/18293
This does two things:
- Rename `iconSizes` to `imageSizes`.
- Give priority to `imageSizes` regardless of `deviceSizes` as a means to opt-out of the srcset behavior.
This separates the `next.config.js` property `images.sizes` into to properties: `images.deviceSizes` and `images.iconSizes`.
The purpose is for images that are not intended to take up the majority of the viewport.
Related to #18122
This updates the fallback 404 handling to render the correct 404 page on the client when a 404 is returned from fetching the data route on a fallback page on the client. This prevents us from having to rely on a cache to be updated by the time we reload the page to prevent non-stop reloading.
This also adds handling in serverless mode to ensure the correct 404 page is rendered when leveraging fallback: 'blocking' mode.
Additional tests for the fallback: 'blocking' 404 handling will be added in a follow-up where returning notFound from `getServerSideProps` is also added.
This makes sure the `locales` are passed to `getStaticPaths` and also disables the removing the default locale from the path when the default locale is the preferred header. It also updates tests to ensure the domain redirects are working as expected.
x-ref: https://github.com/vercel/next.js/pull/17370
This makes sure that we detect the correct default locale for domain specific locales since a domain can have a different default locale residing at the root and we need to check this on the client for prerendered/auto-static pages. This also makes sure we disable the built-in redirect handling when on Vercel since it's handled already.
Tests for this are tricky since we need to load the browser with a custom domain which requires editing the host file. Existing tests should ensure this doesn't break non-domain specific locale behavior though. This was also tested manually while testing https://github.com/vercel/vercel/pull/5298
x-ref: https://github.com/vercel/next.js/pull/17370
This makes sure the correct `initialRevalidateSeconds` field is populated in the `prerender-manifest` for non-dynamic SSG pages since they will be inserted into the `initialPageRevalidationMap` under their locale prefixed variant with `i18n` enabled
x-ref: https://github.com/vercel/next.js/pull/17370
This adds the i18n config items to the routes-manifest so that they can accessed in the builder. This doesn't increment the routes-manifest version as existing value shapes haven't been modified and an additional non-breaking value is being added
x-ref: https://github.com/vercel/next.js/pull/17370
This adds the `locale` prop for `next/link` to allow transitioning between locales client-side and also allows passing the locale to `router.push/replace` via the transition options similar to `shallow` e.g. `router.push('/another', '/another, { locale: 'nl' })`
x-ref: https://github.com/vercel/next.js/pull/17370
This updates to set the `NEXT_LOCALE` cookie to the default locale when the user prefers a different locale from the default in their `accept-language` header but visits the default locale path e.g. `/en-US` with a `accept-language` preferred header of `nl` will set the `NEXT_LOCALE=en-US` header and then redirect to `/`
x-ref: https://github.com/vercel/next.js/pull/17370
Follow-up to https://github.com/vercel/next.js/pull/17370 this adds mapping of locales to domains and handles default locales for specific domains also allowing specifying which locales can be visited for each domain.
This PR also updates to output all statically generated pages under the locale prefix to make it easier to locate/lookup and to not redirect to the default locale prefixed path when no `accept-language` header is provided.
Follow-up PR to #17370 this adds generating auto-export, non-dynamic SSG, and fallback pages with all locales. Dynamic SSG pages still control which locales the pages are generated with using `getStaticPaths`. To further control which locales non-dynamic SSG pages will be prerendered with a follow-up PR adding handling for 404 behavior from `getStaticProps` will be needed.
x-ref: https://github.com/vercel/next.js/issues/17110
This is a follow-up to https://github.com/vercel/next.js/pull/16973 which adds handling for the breaking change in the latest version of css-loader that causes unresolved file references in `url` or `import` to cause the build to fail. This fixes it by adding our own resolve checking and when it fails disabling the `css-loader`'s handling of it.
Fixes: https://github.com/vercel/next.js/issues/17701
Follow-up PR to https://github.com/vercel/next.js/pull/17370 when the path is not prefixed with a locale and the default locale is the detected locale it doesn't redirect to locale prefixed variant. If the default locale path is visited and the default locale is visited this also redirects to the root removing the un-necessary locale in the URL.
This also exposes the `defaultLocale` on the router since the RFC mentions `Setting a defaultLocale is required in every i18n library so it'd be useful for Next.js to provide it to the application.` although doesn't explicitly spec where we want to expose it. If we want to expose it differently this can be updated.
This adds the initial changes outlined in the [i18n routing RFC](https://github.com/vercel/next.js/discussions/17078). This currently treats the locale prefix on routes similar to how the basePath is treated in that the config doesn't require any changes to your pages directory and is automatically stripped/added based on the detected locale that should be used.
Currently redirecting occurs on the `/` route if a locale is detected regardless of if an optional catch-all route would match the `/` route or not we may want to investigate whether we want to disable this redirection automatically if an `/index.js` file isn't present at root of the pages directory.
TODO:
- [x] ensure locale detection/populating works in serverless mode correctly
- [x] add tests for locale handling in different modes, fallback/getStaticProps/getServerSideProps
To be continued in fall-up PRs
- [ ] add tests for revalidate, auto-export, basePath + i18n
- [ ] add mapping of domains with locales
- [ ] investigate detecting locale against non-index routes and populating the locale in a cookie
x-ref: https://github.com/vercel/next.js/issues/17110
This makes sure we have the correct `asPath` value to prevent breaking hydration for `getServerSideProps` pages and doesn't re-use the `resolvedUrl` value for the `asPath` and instead creates a separate `resolvedAsPath` value that only removes the `_next/data` prefix from the path. Additional tests have been added in the `getServerSideProps` suite to ensure correct `asPath` with rewrites.
Fixes: https://github.com/vercel/next.js/issues/17113
On the latest beta of webpack 5 resolving fails with the below error and according to https://github.com/webpack/webpack/issues/11467 is due to the imports in this module not being fully specified. This adds the config mentioned in the thread to correct the resolving for this module.
```sh
Failed to compile.
--
16:33:50.046 | ModuleNotFoundError: Module not found: Error: Can't resolve './assertThisInitialized' in '/vercel/f03cc85/node_modules/@babel/runtime/helpers/esm'
16:33:50.046 | > Build error occurred
16:33:50.047 | Error: > Build failed because of webpack errors
16:33:50.047 | at build (/vercel/f03cc85/node_modules/next/dist/build/index.js:15:918)
16:33:50.099 | error Command failed with exit code 1.
```
Fixes SSG pages that start with `/api` not being detected as SSG pages. This also adds tests to ensure this is working correctly in the `prerender` suite.
x-ref: https://github.com/vercel/next.js/issues/17091
This continues off of https://github.com/vercel/next.js/pull/17081 and provides this normalized `asPath` value in the context provided to `getServerSideProps` to provide the consistent value since the request URL can vary between direct visit and client transition and the alternative requires building the URL each time manually.
Kept this change separate from https://github.com/vercel/next.js/pull/17081 since this is addressing a separate issue and allows discussion separately.
Closes: https://github.com/vercel/next.js/issues/16407
This normalizes the `asPath` for `getServerSideProps` and `getStaticProps` pages to ensure it matches the value that would show on the client instead of a) the output pathname when revalidating or generating a fallback or b) the `_next/data` URL on client transition.
Fixes: https://github.com/vercel/next.js/issues/16542
Earlier today #17038 was merged which I opened to fix a problem when using `webpack@5.0.0-beta.30` with Next.js using the new Webpack 5 support. In that PR, the only change was the renaming of a configuration key. I later discovered that the change on the Webpack side was different than I initially thought, and this meant that the fix I submittted to Next.js didn't work.
This PR intends to fix the remaining problems. Webpack 5 now accepts a `environment` key that can be used to configure the target output. Previously, this was known as `ecmaVersion` and accepted a number. Now, `environment` accepts a configuration object with individual options. I've configured this in such a way where it resembles an ES5 environment:
```js
environment: {
arrowFunction: false,
bigIntLiteral: false,
const: false,
destructuring: false,
dynamicImport: false,
forOf: false,
module: false,
}
```
This PR fixes#17035. As described in the issue, there was a breaking change in `webpack@5.0.0-beta.30`: `output.ecmaVersion` was replaced by `output.environment`. This meant Next.js apps using this `webpack` version would break. This PR updates the relevant Webpack config.
I think this will break any apps that are still using `webpack@5.0.0-beta.29`, but I don't know whether that is a problem as this is a beta feature. If it is, I'd love it if someone could let me know how to detect beta versions in the code so I can make it backwards-compatible.
Babel-preset-env includes includes optional chaining and
nullish-coalescing since [7.8.0](https://github.com/babel/babel/releases/tag/v7.8.0).
In this diff I removed these plugins from next preset to prevent
dependency duplication when their newer versions are out.
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
To prevent FOUC, discussed in #10557 i need to store information about css file dependencies for chunk. Right now current implementation just throws away everything but js.
Can there be more than one css file in chunk? If no - code will be simplified.
closes#10557
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 👍
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
This corrects the case where `/index` is used during revalidation for an optional catch-all route and `index` is passed as a param even though it should be undefined. This also adds test cases to make sure the params are normalized correctly
Fixes: https://github.com/vercel/next.js/issues/16366
