### What?
This PR removes the automatic ESLint linting that previously ran during `next build`. The documentation has been updated to reflect this change.
### Why?
As part of Next.js 16, we're removing the automatic build-time linting that was previously included in the build process. This gives developers more control over when linting runs by explicitly invoking their linter via npm scripts.
### How?
- Updated documentation to clarify that automatic build-time linting has been removed in Next.js 16
- Removed the `runLint` parameter and related linting code from the build process
- Removed the `verifyAndLint.ts` file which is no longer needed
- Simplified type checking code by removing lint-related functionality
- Removed ESLint telemetry during builds
What?
This PR updates the dependency "prettier" from version 3.2.5 to version
3.6.2. It also modifies other scripts by using the pnpm run prettier-fix
after updating the dependency.
Why?
This is updated to benefit from the changes and fixes introduced in the
newer versions of prettier, from versions 3.3 to 3.6.
How?
The package has been updated using pnpm install prettier@latest, and the
files other than package.json and pnpm-lock.json have been modified
using the script pnpm run prettier-fix.
This PR does only have formatting changes introduced by the updated
dependency
This PR is the same as #82719 , with fixes implemented to prevent
prettier to modifiy symlink files
## What?
Update examples `.gitignore` files for parity with [Yarn's official
recommendations](https://v3.yarnpkg.com/getting-started/qa#which-files-should-be-gitignored),
accounting for Yarn's modern Plug-n-Play functionality.
## Why?
New projects initialized with `create-next-app` presently add various
extraneous files from the Yarn cache to the initial commit. This is most
notable in the case of the Next SWC binary, which may exceed 100M in
some environments (empirically, 64-bit Darwin and WSL2 Ubuntu, and very
probably other unix/linux environments), and prevent users from pushing
their new projects to free GitHub repositories without rewriting the
commit history to exclude the extraneous files, or unnecessarily setting
up Git LFS to include them.
## How?
I have errored on the side of exclusion to enable users to push their
CNA projects to GitHub as-is and for parity with other package managers,
while still providing the opportunity to opt in to additional
functionality provided by modern Yarn.
These changes follow the recommendations for
**non**-[Zero-Install](https://yarnpkg.com/features/caching#zero-installs)
configurations, as Zero-Install functionality is an extension on top of
the base package manager experience, and may necessitate additional
configuration and present additional complications for unsuspecting
users, so I think it's best left up to the user to opt-in. On account of
the majority of publicly available Next.js-based projects comprising
general consumer-facing websites, it is my belief that the majority of
Next projects would not benefit from Yarn's Zero-Install functionality,
and that explicitly facilitating it by default would break status quo
with all other non-Yarn CNA projects.
Contrary to the example `.gitignore`s provided by Yarn, I've excluded
the `.yarn/sdks` directory as it contains IDE-specific tooling; I feel
it would be presumptuous for an environmentally-agnostic tool to target
and provide package-manager-specific tooling for specific editors. This
too should be left to the user to opt-in to and provide for their
project if they deem necessary.
I have retained the current `.gitignore`'s exclusion of the `/.pnp`
directory for backwards compatibility with older versions of Yarn (the
files therein have since been reallocated to the `.yarn` directory
addressed by these changes, but I am not clear on when that delineation
occurred or the prevalence of Yarn installations which depend on the
former convention). Maintaining the exclusion here, in the worst case,
implies additional downloads (on an order of magnitude merely similar to
using npm from the outset) rather than failure.
CC: @samcx
### Adding or Updating Examples
- [x] The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`.
See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
Co-authored-by: Sam Ko <sam@vercel.com>
#64186 removed the pages router implementation from the `with-apollo`
example and replaced it with an app router implementation.
Unfortunately, it did so in an unsupported way.
At this point, we can not support any streaming SSR scenario without
additional helper packages - in the case of the app router, it is vital
to use the `@apollo/experimental-nextjs-app-support` package.
This PR switches the example to our officially supported patterns.
<!-- 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
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- 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 #
-->
## Description
This PR ensures that the default prettier config is used for examples
and templates.
This config is compatible with `prettier@3` as well (upgrading prettier
is bigger change that can be a future PR).
## Changes
- Updated `.prettierrc.json` in root with `"trailingComma": "es5"` (will
be needed upgrading to prettier@3)
- Added `examples/.prettierrc.json` with default config (this will
change every example)
- Added `packages/create-next-app/templates/.prettierrc.json` with
default config (this will change every template)
## Related
- Fixes#54402
- Closes#54409
### Reason for making this change
https://yarnpkg.com/getting-started/qa#:~:text=yarn%2Finstall%2Dstate.,your%20workspaces%20all%20over%20again.
In the official documentation of `yarn`, it is stated that `.yarn/install-state.gz` is an optimization file that developer shouldn't ever have to commit. However, currently, when running `create-next-app`, `.yarn/install-state.gz` is being commited.
### Remaining work
I apologize for only modifying one template initially to initiate the discussion first.
If this change is agreed upon, it should be synchronized with other `.gitignore` templates. Would it be possible to follow a similar approach as in https://github.com/vercel/next.js/pull/47241? I would appreciate any assistance in syncing this change.
This PR updates the minimum version of React used by examples from 17.0.2 to 18.2.0.
Fixes#41975
## Bug
- [x] Related issues linked using `fixes #41975`
- [ ] Integration tests added
- [ ] Errors have a 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 a helpful link attached, see `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)
Found that this rule was added but all options are set to `false` so it doesn't do anything. Started with enabling it for examples to ensure minimal breaking of existing PRs.
## 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 by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Use Apollo onError in order to flag GraphQL errors in the next.js server logs in the with-apollo example
https://www.apollographql.com/docs/react/api/link/apollo-link-error/
## Documentation / Examples
- [x] Make sure the linting passes
~⚠️ I lazily created this PR from Github directly as I don't have a local build of next.js on my current machine.
If ever linting does not pass, I will update this later today (sorry for the noise).
EDIT: it does not, I will update this PR shortly.~
This PR updates the docs and examples for `create-next-app` to include pnpm usage.
The following script was used to update every example README:
```js
const fs = require('fs')
const examples = fs.readdirSync('./examples')
for (let example of examples) {
const filename = `./examples/${example}/README.md`
const markdown = fs.readFileSync(filename, 'utf8')
const regex = new RegExp(`^yarn create next-app --example (.*)$`, 'gm')
const output = markdown.replace(regex, (yarn, group) => {
const pnpm = `pnpm create next-app -- --example ${group}`
return `${yarn}\n# or\n${pnpm}`
})
fs.writeFileSync(filename, output)
}
```
## Description
This year we implemented the new Apollo config using this example. We recently moved to `getServerSideProps` as well, however, this was giving us some cache problems. The issue was that the cache was older than the actual data that was coming from the server side query.
Because the `merge` of the cache in `apolloClient.js` is merging the existingCache in the initialState it will overwrite the "fresh" initialState with properties that already exists. This means that if you have something in your cache from previous client render, for example `user` with the value `null`, and you go to a new page and do a new query on the server which returns a value for the `user` field, it will still return `null` because of that `merge` function.
Since this was weird in our opinion, we've changed this in our own environment by always overwriting the existing cache with the new initialState, so that the initialState that is coming from a fresh server side query is overwriting. We thought it was a good idea to reflect this also in this example, because we couldn't think of a reason why the existing cache should overwrite fresh queries.
I've added a reproduction that shows what this is exactly about. I hope my description makes sense, let me know what you think!
## Reproduction of old scenario
Created a reproduction branch here: https://github.com/glenngijsberts/with-apollo-example. Using a different API than in the example, because of https://github.com/vercel/next.js/issues/32731.
1. checkout the example
2. yarn
3. yarn dev
4. visit http://localhost:3000/client-only
5. Hit "Update name". This will run a mutation that will update the cache automatically. Because I use a mocked API, the actual value on the API won't be updated, but this is actually the perfect scenario for the problem because in reality data can already change in the meantime when you're doing a new request.
6. Go to the SSR page
7. This will display two values: one is coming from the server side request (which is the latest data, because no cache is used in `getServerSideProps`) and the other is using the cache, which is outdated at that point, yet it's still returned because the old way of merging the cache was picking the existing cache over the initialState that was coming from the fresh server side query.
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
This PR removes the duplicate overview link for data fetching, and fixes the corresponding links
## 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 by running `yarn lint`
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
* Add licences to all example/package.json that lack them
* Revert "Add licences to all example/package.json that lack them"
This reverts commit 5d4e25012f.
* Update check-examples to remove `license` field from examples
* Remove `license` from all examples.
This was mentioned in vercel/next.js#27121 but it looks like it didn't end up being in the merge?
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Clean up package.json files in the `examples` directory:
- Add `private: true`
- Remove `version` (because they are irrelevant for packages that are not meant to be published)
- Remove `name` (because they are optional for packages that are not meant to be published, and when someone clones an example, they often rename it and the property becomes stale)
- Remove `author`
- Remove `description`
- Remove `license`
Also remove `with-dynamic-app-layout` example completely, since it does the same as `layout-component` (https://github.com/vercel/next.js/pull/27121#discussion_r668178408).
## Documentation / Examples
- [x] Make sure the linting passes
[With next 11 requiring react 17](https://nextjs.org/blog/next-11#upgrade-guide), most of the examples
need to be updated, so the following snippet updated all the examples to
a compatible react version.
```bash
cd examples/
fd -g 'package.json' | xargs sed -r -i 's/"react": ".*"/"react": "^17.0.2"/
fd -g 'package.json' | xargs sed -r -i 's/"react-dom": ".*"/"react-dom": "^17.0.2"/'
# exclude experimental react version
git checkout with-reason-relay/package.json
```
The intention is to show people the correlation between things, in this case, understand the usage of the same key from the props and the rehydration.
Hopefully, this change will bring value as it has done with some Juniors already.
**What's the problem this PR addresses?**
A decent amount of the examples don't have a `name` field in `package.json` that matches their folder name, meaning they either lack a name or the names are duplicated.
I was testing Yarn 2 workspaces using the entire examples directory and needed to get rid of the duplicates.
**How did you fix it?**
Updated the names to match the names of their folders
## Motivation
As Graphcool is being shutdown, we replaced all the graphcool api endpoints with some handcrafted APIs using Prisma & Nexus, that can be found here https://github.com/prisma-labs/nextjs-graphql-api-examples. These GraphQL endpoints are now deployed to Vercel.
## Notes
- I couldn't get the reason-relay example to run. Given that the relay endpoint works on the other relay example, I don't see any reason why it wouldn't work on that one
- The `with-apollo` example is buggy when creating some posts, but nothing related to the switch of the api endpoint as it was already buggy before. I suspect the `concatPagination` strategy to be the cause of that bug, but I couldn't figure it out.
Fixes#14780
Based on https://github.com/vercel/next.js/pull/13607 - I created a new PR as I can't push changes to the initial PR.
Migrated the Apollo client to use SSG, also removed the link to the live demo because I don't know who the owner is or how to update the deployment.
The implementation is pretty simple and will be added to all the other Apollo examples
Ben Gubler
