## What?
While looking at the CPU profile of booting up Vercel's site I noticed
that we call `getPageStaticInfo` a lot. Looking into this more it turns
out `getPageStaticInfo` is currently called for all routes, `pages` and
`app`, even though the data is only being used to keep track of which
routes are edge functions, however, this is already tracked as part of
the build output so this didn't make sense to me. First I tried
commenting out this entire block and all tests were passing, so I
removed it except for middleware as middleware can provide a `matcher`
which does need to be known before compiling the file as of right now.
After that change a different set of tests started failing, specifically
the one that checks if we warn correctly. Interestingly by fixing
`getPageStaticInfo` being called early and for all routes it also caused
these warnings to no longer trigger as there was a case in the manifest
plugin that called `getPageStaticInfo` with less information. Calling
`getPageStaticInfo` there was not needed either as we call
`getPageStaticInfo` at the beginning of the build for each entrypoint so
we already have the information required, it just had to be passed down
so that the manifest plugin could use it.
For Vercel's site this change improves booting the dev server by over 1
second.
Related to #48748
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Given the amount of CSS ordering problems mentioned in the issue queue
(see #16630), it's clear, for most people, that it is NOT obvious that
the order of CSS concatenation matches the order of importing CSS and
modules inside `_app.js`.
We should try to make this fact explicit in the docs. Right now, it's
only implied.
## Documentation checklist
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Updating the `with-sentry` example with latest dependencies versions, new feature docs, and also converted it to TypeScript.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`
- [x] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What?
Adds mikroORM to external package list
### Why?
To prevent developers using
[MedusaJS](https://github.com/medusajs/medusa) modules with NextJS from
having to add this in their next config.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
I added a small change to the `with-docker-compose` example to show how to make the provided `.env` file usable.
### Why?
I struggled to understand why I could not get environment variables to work as intended and thought this small change might help someone else new to docker in the future.
### How?
Added a few comments to the `docker-compose.dev.yml` file, along with showing how to utilize a `.env` file with docker-compose
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What?
The TypeScript Stripe example has been fixed to address various issues. One of the issues was related to calling a function, which has now been resolved. Additionally, the Stripe API used in the example was outdated, causing an error during the build process. This issue has also been fixed.
By making these fixes, the TypeScript Stripe example should now work correctly without any function calling issues or errors related to the outdated Stripe API during the build.
### Why?
There's an issue regarding this problem `Fix with typescript stripe example fixes #50541`
```console
$ next build
- info Linting and checking validity of types ..- error ESLint must be installed in order to run during builds: yarn add --dev eslint
- info Linting and checking validity of types ...Failed to compile.
./components/CartSummary.tsx:41:24
Type error: Argument of type '{ sessionId: any; }' is not assignable to parameter of type 'string'.
39 | }
40 |
> 41 | redirectToCheckout({ sessionId: response.id })
| ^
42 | }
43 |
44 | return (
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
### How?
- Calling the `redirectToCheckout` function the right way 275cb65f3d/use-shopping-cart/react/index.d.ts (L65)
- Updating Stripe API
- Fix some changed / depcrated code since the API has changed a little
- Fix a TS error since the used library does not has a correct TS defintion file
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
When navigating to a route with a hash parameter, the layout router
jumps to the element by scrolling to the node's `offsetTop` value.
However, this will ignore `scroll-padding`, which deviates from browser
behavior.
It looks like this isn't an issue in the pages router which currently
makes use of
[`scrollIntoView`](https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/router/router.ts#L2262).
Closes NEXT-1171
Fixes#49612
---------
Updates the `with-storybook` example to be the example located in [`vercel/vercel`](https://github.com/vercel/vercel/tree/main/examples/storybook).
The motivation for this change is that we now have better support for storybook. It is now treated as its own framework and so users can specify the `storybook` framework as well as custom build command `build-storybook` in order to get near zero-config support 🌟
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [X ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [X ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Add all available options to cli commands
Consistent formatting for all options
### Why?
Options were not consistent across all commands, some were missing
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
It's not totally clear from the docs that using `NEXT_PUBLIC_` env vars
will be a problem for pipelines that deploy the same image to multiple
environments (this bit us in a production incident). This PR is an
attempt to make it clear. Open to feedback/suggestions!
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Add @leerob as an optional global code owner. This means he won't be
tagged for reviews on every PR, but he can approve PRs. This allows the
@vercel/devex to make changes more quickly, without having to distract
the Next.js team.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
These docs were wrong because `./pages` is not sufficient to run a
codemod.
Imagine a project that has `./components` and `./pages` and many
directories for example.
Also its important to run at the root of the Next.js project so that the
path has a `next.config.js` because some codemods modify that config.
Tweak code owners after some testing and feedback.
- Move the Next.js team up to be optional global code owners (so that everyone can review but are not tagged for review). Global individuals should still be tagged if there are no specific `.vercel.approvers` files in subdirectories.
- Adds @vercel/devex to image files so there's coverage on those files for the docs
- Target specific folder and files for Styfle to get notified
- Deletes some rules in the old GitHub codeowners
This removes the `__internal_nextjs_integration_test` compile-time feature. This would end up requiring an additional set of build targets for running integration tests was only used for two cases:
* Determining whether to read from an env var to load mocked Google fonts responses in next/font/google tests. This now uses the presence of this variable to determine whether to use mocked responses.
* Enabling the `next-dev/serializable` feature. This is now set directly instead.
Test Plan:
* Integration tests with Turbopack.
* Manual test of next/font/google with Turbopack
Both of our bundlers won't split different exports of a module into different chunks, we can rely on https://github.com/facebook/react/pull/26624 to simplify the structure. This reduces the size of the client reference manifest by ~70%.
Apparently the object deconstruction in the example doesn't work. This PR proposes a working version:
```diff
- export default function Page({ params: { slug: string } }) {
- return <div>My Post: {slug}</div>
- }
+ export default function Page({ params }: { params: { slug: string } }) {
+ return <div>My Post: {params.slug}</div>
+ }
```
According to the [page reference](https://nextjs.org/docs/app/api-reference/file-conventions/page), the page function parameter slugs needs to be retrieved by calling `params.slug`.
The TypeScript section below shows the correct function type signature, although not referencing to the parameter.
Added missing APIs, also sorted all of them alphabetically to make it
easier to read.
---------
Co-authored-by: Delba de Oliveira <delbabrown@gmail.com>
