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