Currently `new URL()` for server assets is completely broken because of the `publicPath` that is used for them too. `new URL()` for SSR is broken on windows as it's using absolute urls on the windows filesystem. And `new URL()` is using an incorrect filename
* Place all `asset`s correctly in `/_next/static/media` with `[name].[hash:8][ext]`
* Added a separate runtime chunk for api entries, without `publicPath`
* Introduce separate layer for api entries, which uses server-side URLs.
* Otherwise new URL() will return a faked relative URL, that is identical in SSR and CSR
* Disables react-refresh for api entries
Fixes#27413
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## 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
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
* Update headings to clarify that we're describing. Add heading for Authentication API Routes
* Start adding API route examples
* Start adding API route examples
* Start adding API route examples
* Start adding API route examples
* auth: Replace clerk packages with @clerk/nextjs
* Add API authentication example to with-clerk
* Fix footer links
* Proofread, ensure consistency
* Update example's props to use new version
* Update example links
* Add rel tag to _blank link
* Obscure the authentication provider in the example
* Replace example
* Reset authentication docs, list Clerk as vendor
* Re-fix typo
* Change sample to example
* Add the example
* Update examples/with-clerk/package.json
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: Peter Perlepes <p.perlepes@gmail.com>
Co-authored-by: Lee Robinson <me@leerob.io>
## Bug
- [x] Related issues linked using [`#29179`](https://github.com/vercel/next.js/issues/29179)
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## 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.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
Fixes: https://github.com/vercel/next.js/issues/29179
This PR makes two changes:
- It updates the index page to reflect the fact that `withSentry` should now be working for API routes deployed to Vercel.
- It changes the route which returns a promise rejection to be more obvious about the fact that that's what it's doing.
Fixes#16442
The current instructions on the Debugging page currently only work for server-side code, and furthermore, the page doesn't actually _say_ that they only work for server-side code.
This update adds instructions for debugging client-side code in both VS Code and Chrome DevTools. It also improves the suggested VS Code launch configurations to take advantages of some relatively recent features in VS Code's [built-in JavaScript debugger][1]. Using the `node-terminal` and `pwa-chrome` launch types removes the need to manually pass an `--inspect` flag to the underlying Node.js process.
[1]: https://github.com/microsoft/vscode-js-debug
Let me know if there are any edge cases I didn't consider with these VS Code launch configs!
## Documentation / Examples
- [x] Make sure the linting passes
* Remove inert font tag in font optimization
* Fix lint
* Remove inert font tag during font optimization
* Fix lint
* Fix lint
* Fix lint
Co-authored-by: JJ Kasper <jj@jjsweb.site>
After talking with markerikson, I've made some updates to the Redux examples:
- Updated the `with-redux` example to use the Redux Toolkit + TypeScript example
- Updated dependencies of `with-redux` to work with latest testing setup
- Removed `with-redux-toolkit` in favor of `with-redux`
- Removed `with-redux-toolkit-typescript` in favor of `with-redux`
- Removed `with-redux-code-splitting` in favor of `with-redux`
Includes a fix for when a tree is rendered without the styled-jsx registry being provided. It'll noop in this new version.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## 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.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
This fixes segments inside of the host of the destination failing to parse with url.parse due to the unexpected colon by escaping the colon for segments and then unescaping them after we have parsed the URL.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
x-ref: https://github.com/vercel/vercel/pull/6713
* Throw error if res is accessed after gSSP returns
Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.
With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.
* fixup! Throw error if res is accessed after gSSP returns
I also removed the custom server link here, because I think it's making too strong of a correlation between custom server and Node.js server using `next start`, which aren't the same.