Add description for `--use-npm` flag that shows up as part of the help information.
## 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 PR addresses the potential for memory leakage with the previous caching scheme; it should also be more efficient, resulting in fewer instances where a fresh Babel config must be generated. Documentation has been added, and `overrides` have been removed in favor of conditional plugins for consistency.
This approach is easier to break, in that `CharacteristicsGermaneToCaching` must be correct for all cases. However, it means that <= 8 configs will need to be generated within the context of a single thread, and the config-caching is about as fast as we can get it.
Solves an issue some users ran into where enabling webpack 5 highlighted a wrong JSON import where named exports were used for JSON data.
> Should not import the named export 'myValue' (imported as 'myValue') from default-exporting module (only default export is available soon)
Fixes the e2e PnP tests by updating `enhanced-resolve` to get the fix in https://github.com/webpack/enhanced-resolve/pull/289, the tests started failing in https://github.com/vercel/next.js/pull/23810
## 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
* import next-server logic during the time the configuration is loaded
* load minimizer plugins only when used
* load ReactDevOverlay only when used
* load only meta information of tsconfig for validation
* make worker for configuration loading lighter
* only load runTypeCheck when used
* load postcss config only when used
Noticed in this issue the reproduction was using `getStaticPaths` on a non-dynamic page incorrectly although we don't currently show an error for this.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
x-ref: https://github.com/vercel/next.js/issues/22931
This ensures we don't attempt adding a locale to a path when the locale is already present but in a different casing, this also ensures we successfully remove the locale if the casing differs in the path. Additional tests have been added in the `i18n-support` suites to ensure this is working correctly.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23553
This fixes dynamic pages with `fallback: false` that don't have a matching path causing a 404 before rewrites are checked unexpectedly. This ensures we treat `fallback: false` pages as a match only if they also have a matching static path so that fallback rewrites can be triggered correctly. An additional test suite as been added to ensure this is working as expected.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
Follow PR to #23887 to add next/image.
Only other change was wrapping the image in a span to allow for the margin that was previously on the actual `<img>`
## Documentation / Examples
- [x] Make sure the linting passes
relevant changes:
* performance improvements for `export *` and reexports
* fixes incorrect cache invalidation when new properties are added to the DefinePlugin (fixes#23901)
Document `--use-npm`.
## 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
- [x] Make sure the linting passes
Just cleans up some code, doesn't change the underlying mechanism
## 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 is a follow-up to https://github.com/vercel/next.js/pull/23588 to update to use a regex lexer to gather the named regex groups instead of attempting to gather them through executing the regex since it can fail to gather the regex groups when they are using specific matching. This also ensures we don't pass the value as a segment when value is defined and it doesn't use a capture group. Additional tests are added to cover these cases and documentation updated to reflect this.
Closes: https://github.com/vercel/next.js/issues/23415
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
## Documentation / Examples
- [x] Make sure the linting passes
This PR adds the deduplication logic to image optimizer so the cache will be reused as much as possible if there're multiple concurrent requests.
Fixes#23436.
## 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
- Enable webpack 5 by default for apps without custom webpack configuration
Fixes#23143
## 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 ensures we match dynamic routes correctly when applying `check: true` behavior with i18n so that no-op rewrites match dynamic routes correctly.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23854
Tobias has fixed the `compiler.hooks.invalid.call()` bug in webpack 5 so this is no longer needed
## 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
https://github.com/webpack/webpack/releases/tag/v5.31.1
## 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
@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)
* fixes a bundle size regression from webpack 4 to 5
* fixes these warnings during resolving build dependencies for packages using `exports`
## 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 ensures we don't reach the invariant from trying to create the export progress with no items during `next build` or `next export` by returning immediately when we notice there are no paths being exported. Additional tests have been added to ensure these cases don't error.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23724
This ensures we are checking the filesystem correctly when i18n is used to prevent fallback rewrites from being applied even when a page is matched. Additional tests have been added to ensure these cases are being handled.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23577
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
Follow up to #23614. `resolvedAsPath` isn't actually even being used as an output, we're just mutating it for convenience. If we do want to output it in the future, we can do it a different way (i.e. via return).
This ensures we don't parse the default params when auto-exporting dynamic routes with i18n since the page and path aren't equal when localized. This adds an additional test case to ensure we don't regress on this behavior in the `i18n-support` test suites.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23167
* has some memory usage improvements
* after a while cache entries that are unused and already persistent to disk are removed from the memory cache
* When are read again, they are restored from disk again
* Should play well together with adding and removing pages due to on-demand-entries
## 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 PR updates the Squoosh PNG decoder, which fixes#22929 in GoogleChromeLabs/squoosh#971.
## Bug
- [x] Fixes#22929
- [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 ensures we gather segments from the experimental has field when validating segments used in the destination to prevent the invalid segments in the destination error from showing incorrectly. This usage has been added to the custom-routes test suite to ensure the segments are passed correctly from the has field.
Fixes: https://github.com/vercel/next.js/issues/23415
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
* Mark this.router protected
Seems that some people (#23558) are using Next.js internals based on the typings that TS generates automatically even though these values are not documented / should not be used in applications. This ensures the router value on Server is not used by accident.
* Mark all variables as protected
https://github.com/vercel/next.js/issues/23349
* fix type error
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This RP fixes the problem that the image optimization API uses a large amount of memory, and is not correctly freed afterwards. There're multiple causes of this problem:
### 1. Too many WebAssembly instances are created
We used to do all the image processing operations (decode, resize, rotate, encodeJpeg, encodePng, encodeWebp) inside each worker thread, where each operation creates at least one WASM instance, and we create `os.cpus().length - 1` workers by default. That means in the worst case, there will be `N*6` WASM instances created (N is the number of CPU cores minus one).
This PR changes it to a pipeline-like architecture: there will be at most 6 workers, and the same type of operations will always be assigned to the same worker. With this change, 6 WASM instances will be created in the worst case.
### 2. WebAssembly memory can't be deallocated
It's known that [WebAssembly can't simply deallocate its memory as of today](https://stackoverflow.com/a/51544868/2424786). And due to the implementation/design of the WASM modules that we are using, they're not very suitable for long-running cases and it's more like a one-off use. For each operation like resize, it will allocate **new memory** to store that data. So the memory will increase quickly as more images are processed.
The fix is to get rid of `execOnce` for WASM module initializations, so each time a new WASM module will be created and the old module will be GC'd entirely as there's no reference to it. That's the only and easiest way to free the memory use of a WASM module AFAIK.
### 3. WebAssembly memory isn't correctly freed after finishing the operation
`wasm-bindgen` generates code with global variables like `cachegetUint8Memory0` and `wasm` that always hold the WASM memory as a reference. We need to manually clean them up after finishing each operation.
This PR ensures that these variables will be deleted so the memory overhead can go back to 0 when an operation is finished.
### 4. Memory leak inside event listeners
`emscripten` generates code with global error listener registration (without cleaning them up): https://github.com/vercel/next.js/blob/99a4ea6/packages/next/next-server/server/lib/squoosh/webp/webp_node_dec.js#L39-L43
And the listener has references to the WASM instance directly or indirectly: https://github.com/vercel/next.js/blob/99a4ea6/packages/next/next-server/server/lib/squoosh/webp/webp_node_dec.js#L183-L192 (`e`, `y`, `r`).
That means whenever a WASM module is created (emscripten), its memory will be kept by the global scope. And when we replace the WASM module with a new one, the newer will be added again and the old will still be referenced, which causes a leak.
Since we're running them inside worker threads (which will retry on fail), this PR simply removes these listeners.
### Test
Here're some statistics showing that these changes have improved the memory usage a lot (the app I'm using to test has one page of 20 high-res PNGs):
Before this PR (`next@10.1.0`):
<img src="https://user-images.githubusercontent.com/3676859/113058480-c3496100-91e0-11eb-9e5a-b325e484adac.png" width="500">
Memory went from ~250MB to 3.2GB (peak: 3.5GB) and never decreased again.
With fix 1 applied:
<img src="https://user-images.githubusercontent.com/3676859/113059060-921d6080-91e1-11eb-8ac6-83c70c1f2f75.png" width="500">
Memory went from ~280MB to 1.5GB (peak: 2GB).
With fix 1+2 applied:
<img src="https://user-images.githubusercontent.com/3676859/113059207-bf6a0e80-91e1-11eb-845a-870944f9e116.png" width="500">
Memory went from ~280MB to 1.1GB (peak: 1.6GB).
With fix 1+2+3+4 applied:
<img src="https://user-images.githubusercontent.com/3676859/113059362-ec1e2600-91e1-11eb-8d9a-8fbce8808802.png" width="500">
It's back to normal; memory changed from ~300MB to ~480MB, peaked at 1.2GB. You can clearly see that GC is working correctly here.
---
## Bug
- [x] Related issues #23189, #23436
- [ ] 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 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
If the upstream MIME type isn't prefixed with `image/`, the endpoint should directly response with a 400 error.
## Bug
- [x] Fixes#23312
- [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 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
fixes some bugs and improves performance
## 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 is a follow-up PR of #19052, where `visibility: inherit` was mistakenly added back. It was removed in #23278.
## 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
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
The current `<Image />` component does not fallback gracefully when JavaScript is disabled in the client / browser.
You can test this with the [official Next/Image example](https://csb-4k0kr-p8ya8f304.vercel.app/), by disabling JavaScript in the browser's DevTools. Video demo: https://streamable.com/frkvw9
This PR aims to fix this behaviour by using `<noscript></noscript>` tags to conditionally display a standard `<img>` element using the `props` passed to `<Image />` when JavaScript is disabled.
For browser sessions where JavaScript is enabled, this will not cause an increase in network requests, so there should be no downside.
One area where this PR is a bit "hacky" is that it uses a negative `margin-top` to counteract `sizerStyle.paddingTop`. From what I can tell, `sizerStyle.paddingTop` is generated on the server side, where we can not know ahead of time whether JavaScript is enabled in the browser - hence why I've opted for this solution.
Fixes#19223Fixes#21214
This PR removes the `visibility` style property change from next/image. It was previously added in #18195 to fix a bug that when no `src` is set, and that bug is not valid anymore as all images will always have `src` (and a fallback too).
It also fixes the problem that screen readers ignore elements with `visibility: hidden`.
Fixes#23201.
## Bug
- [x] Related issues #23201
- [ ] 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#23125
fixes https://github.com/tailwindlabs/tailwindcss-jit/issues/54
## 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
Currently Next.js exposes internal code in the error overlay if certain errors were created from the user code. Some examples were attached in #20776.
We can clearly see that the path is wrong (`../next-server`), it should be `./node_modules/next/dist/next-server`:
![CleanShot 2021-03-19 at 01 33 04](https://user-images.githubusercontent.com/3676859/111670728-1ae7e400-8853-11eb-9213-3b359798900e.png)
The root cause is the `__nextjs_original-stack-frame` middleware resolves the file path with the following code:
```js
path.resolve(
rootDirectory,
getSourcePath(sourcePosition.source)
)
```
where `rootDirectory` is the **app root**, but `sourcePosition.source` comes from the module path, which is relative to the path of the `next` binary, not the app root.
That explains why we see `../next-server` from the error above, because it's relative to `./node_modules/next/bin/next`.
Because of that, the resolved result will never have `node_modules` in its path and it won't be filtered by the error overlay in the UI. Here's a screenshot of the frame object in the UI:
![CleanShot 2021-03-18 at 23 01 29@2x](https://user-images.githubusercontent.com/3676859/111670062-65b52c00-8852-11eb-9293-3a6e5b7c4b9b.png)
And the filter we use to determine if a frame is expanded or not only depends on `body.originalStackFrame`:
```js
expanded: !Boolean(
body.originalStackFrame?.file?.includes('node_modules') ?? true
)
```
So this PR also adds `source.file` check to ensure they will be ignored (not necessary because we fixed the path resolving).
Fixes#20776.
## 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 ensures we exit the build process after the build completes even if timers/connections are left open since this can cause the process to hang indefinitely. This was the previous behavior although got changed un-intentionally in e27b7e996d
This updates our production test with an open timer to ensure it doesn't block the process from completing.
As stated in #23157, this PR merges all the operations into 1 worker thread (`processBuffer` in `impl.ts`) and only pass a list of operation names and args into the worker. This should improve the speed and memory usage of next/image.
Fixes#23157. X-ref: #22925.
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.
# Route Announcements
## Summary
This PR improves the accessibility of NextJS's client-side navigation by announcing route changes to screen readers.
## Context
When a user who is sighted clicks on a link, they can see the content change. It's an affirmation that what the user intended to do by clicking a link actually worked! Users navigating the page via a screen-reader will not get this feedback on NextJS sites (This is an issue on many SPA-like architectures).
https://user-images.githubusercontent.com/4213649/103017382-63b02b00-44f8-11eb-9940-fb530d2d3018.mov
## Solution
Whenever there is a route change, the new `<RouteAnnouncer />` will look for a name to give the new page and then announce it! The name is found by first looking for an `h1`, falling back to `document.title`, and lastly to `pathname`. `<RouteAnnouncer />` is a visually hidden component placed within the `<AppContainer />`.
## Demo
https://user-images.githubusercontent.com/4213649/103017401-6ad73900-44f8-11eb-8050-b3e9a7e0c3f2.mov
## Inspiration
First and foremost, this PR was inspired by @marcysutton's studies and writing, [What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs
](https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/) as well as @madalynrose's [Accessible Routing](https://github.com/gatsbyjs/gatsby/pull/19290) PR for Gatsby.
There were also learnings gleaned from the conversations within #7681.
### Related Issues & PRs
- Resolves#7681
- Relates to #19963
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
Currently if you have `sizes` set in `next/image`, the image will likely be downloaded multiple times (usually twice) on Safari (macOS and iOS): the correct size for the viewport, and the original size specified in `src`.
Also make sure you have "Ignore Resource Cache" disabled in the Safari Devtools when trying to reproduce:
![CleanShot 2021-03-09 at 21 05 54@2x](https://user-images.githubusercontent.com/3676859/110476820-6399f180-811d-11eb-93ec-5b2482c87884.png)
The root cause is the way Safari handles `<img>`'s attribute updates. Although React updates all the attributes one by one synchronously and programmatically, Safari will still try to fetch the resource immediately and won't wait for other DOM changes to be finished.
That means if we set the following 3 attributes in this order: `src`, `srcSet`, `sizes`. Safari will fetch the image when `src` is set. And then once `srcSet` is there it will fetch the resource again based on it. And finally, when `sizes` is updated it might correct the resource URL again.
So the fix here is simple: by just reordering those to `sizes`, `srcSet`, `src`, it will only load the image with the correct size only once:
<img width="1498" alt="CleanShot 2021-03-09 at 21 05 30@2x" src="https://user-images.githubusercontent.com/3676859/110477852-a27c7700-811e-11eb-88dc-d6e7895f67bd.png">
Fixes#19478.
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 all env values before loading `next.config.js` since these values can be used in there. This also updates to ensure we're testing these values are available while loading `next.config.js` so we don't regress on this.
Fixes: https://github.com/vercel/next.js/issues/22811
This ensures we don't export `/404` during the automatic static optimization during build when the `/404` isn't static and won't be used/copied to the final output.
x-ref: https://github.com/vercel/next.js/issues/22815
This PR adds request deduplication for `_getServerData`. If a request with the same URL is already in-flight, we don't send another new request. When a request succeeds or fails, we delete the cache.
A potential improvement this brings is, when `getServerSideProps` of a new route is slow to load, the user might keep clicking on the link which causes new requests, and the route will never update because results of old requests were ditched. Also adds a test case for this scenario.
Closes#19238.
In the current implementation, `idleTimeout` will always be thrown even if it didn't time out and `Promise.race` was resolved. This causes the error `Error: Route did not complete loading` on every route transition and Chrome Devtools will pause code execution if you have "Pause on exceptions" enabled.
This PR adds `resolvePromiseWithTimeout` which does the same thing as `Promise.race` and `idleTimeout`, but it cancels the rejection when it resolves successfully, in which case the error won't be thrown.
Fixes#21543.
This fixes the case where index page revalidation would match a dynamic page instead of the index page from the pathname not being denormalized.
Fixes: https://github.com/vercel/next.js/issues/22750
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
We do have a third argument on `processEnv` to customize the console instance, however `processEnv` relies on `processEnv` which also have the same argument for the same purpose but it's not forwarded from `processEnv`.
Was there a purpose for it to be left out ? If not I would expect it to be forwarded 😄
Closes: https://github.com/vercel/next.js/pull/21788
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 ensures `distDir` is set under `renderOpts` in `next-server` so that it is present when experimental `optimizeCss` is enabled.
x-ref: https://github.com/vercel/next.js/pull/16539
Currently, the image component doesn't handle use of the `sizes` property with `layout="fill"` and `layout="responsive"` very well for small viewports. It will never include sizes smaller than the smallest viewport (640px) in the srcset, so even if you specify `sizes="30vw"` in your image, you have to download the full-viewport-width image on small devices.
This PR adds logic such that if you use `layout="fill"` and include a `sizes` property, the image component will include the full range of image sizes in the `srcset`.
It also includes an optimization where it finds the smallest `vw` value in the sizes value and combines that with the smallest viewport width, and uses that as the floor of the srcset. It does this so it doesn't unnecessarily increase transfer size by including ALL sizes. This is still a conservative optimization--for 95% of cases, taking the _largest_ `vw` size would work, but I don't see a way to do that without breaking a few corner cases.
The case of a sizes prop with `px` values is fixed but not optimized--though generally that case is less of a good fit for the fill or responsive layout anyway.
This ensures we handle resolve rewrites during prefetching the same way we do during a client-transition. Previously if a rewritten source was used in an `href` neither the page bundle or SSG data if needed would be prefetched although would work correctly on a client transition.
Fixes: https://github.com/vercel/next.js/issues/22441
Follow-up to https://github.com/vercel/next.js/pull/22139 this ensures the default 500 error page hydrates with the correct `statusCode` prop when updating query values on the client since currently it will switch the 404 `statusCode` when one isn't present. An additional test case has been added to ensure this is handled correctly.
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.
This should resolve the typing issues described in https://github.com/vercel/next.js/issues/21390 from the webpack inlining, by declaring `next/dist/compiled/webpack` in the main typing file as a source.
@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
I tried the preset provided at `packages/next-plugin-storybook` but it was raising error due to an [unsafe negation](https://eslint.org/docs/rules/no-unsafe-negation) in the `preset.js` file.
I added a test to show the error:
```
● next-plugin-storybook filterModuleRules › should filter module rules correctly
TypeError: rule.test.test is not a function
48 | if (!rule.test instanceof RegExp) return true
49 | // use Next.js' built-in CSS
> 50 | if (rule.test.test('hello.css')) {
| ^
51 | return false
52 | }
53 | // use next-babel-loader instead of storybook's babel-loader
at filter (../packages/next-plugin-storybook/preset.js:50:21)
at Array.filter (<anonymous>)
at Object.filterModuleRules (../packages/next-plugin-storybook/preset.js:46:28)
at Object.<anonymous> (unit/webpack-config-overrides.test.js:12:36)
```
The original type for `GetServerSidePropsContext.req.cookies` was introduced in #19724. In the PR, the test at `test/integration/typescript/test/index.test.js` expects req.cookies to always exist, so `req.cookies` will never be undefined.
I'm guessing that req.cookies is parsed using the same cookie middleware as `NextApiRequest`, in which case `req.cookies` should be `{ [key: string]: string }`, not `{ [key: string]: any }`.
Closes#17042
I removed mkdirp from package.json taskfil.js, and ran `yarn && ./check-pre-compiled.sh `. Please let me know if anything else is needed!
(Extracted from #20411)
Note that now compiled webpack has mkdirP function
Fixes: https://github.com/vercel/next.js/issues/20370
> AsPath is incorrect on Server if you use rewrites and getInitialProps. On the server, asPath is the rewritten asPath while on the client asPath ist as given in the request URL.
The same issue was used to happen on `getServersideProps`, but it was fixed in this PR (https://github.com/vercel/next.js/pull/17121).
`getInitialProps` needs same fix except when the target is serverless, which has correct `asPath` value.
Additional tests have been added in the `getInitialProps` suite to ensure correct asPath with rewrites.
As discussed with @csswizardry. This is a temporary option in case you know the preloads are not needed. It will likely be a default once the ScriptLoader work from @janicklas-ralph has been proven in partner apps and landed.
```js
// pages/index.js
export const config = {
unstable_JsPreload: false
}
```
Running next.js in `development` causes issues when having pages named "development" or "developments",... as `this.buildId` = `development`
Fixes: https://github.com/vercel/next.js/issues/19520