Fixes#38533 by including `src/` as a default linting directory where all files within are linted
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
[Slack thread](https://vercel.slack.com/archives/C02UJ0QH45Q/p1656580818197009)
## 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)
Readds `@next/next/no-assign-module-variable` ESLint rule that was inadvertently removed in #34335 during the resolution of many merge conflicts.
This PR will get us back to a good / working state. I'll see if I can add a test to ensure all rule are accounted for in a separate PR.
Fixes#34335.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [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)
This rule was good and kinda made sense when we had nested Middleware.
Now that we have a single Middleware, one might extract logic into different places
and I don't think we should limit importing `NextResponse` or `NextRequest`.
## Related
- Closes#36239
- Closes#37309
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The paths starting with slashes in the ESLint config examples are absolute, which are almost never the correct configuration for a project. Using a relative path is a much more common configuration, and leads to much less debugging why these examples don't work.
## 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`
The current example attempts to remove resolve the relative pathname of the absolute pathnames given by `lint-staged` using string manipulation and `process.cwd()`. This is a risky solution because pathnames have many platform dependent edge cases. The example also returns pathnames that are technically wrong in linux. `/home/project/file => /file`,
I propose to use the utilities provided by node.js to resolve the relative pathnames, and to format the sample `.lintstagedrc.js` file in a manner easier for novice programmers to understand and modify.
## 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
- [x] Make sure the linting passes by running `yarn lint`
Added install instructions for eslint-config-prettier before adding Prettier to the ESLint config.
## 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
- [X] Make sure the linting passes
This adds a new ESLint rule to `eslint-plugin-next` to check that `next/script` components with inline content have the required `id` attribute.
Also adjusted the code example for inline scripts in the `next/script` docs, which were actually missing an `id` attribute.
And also updated the `next/scripts` integration test to also have the required `id` attribute.
Unsure about the required heading levels in the errors .md document (other examples have h1 and h4??)
## 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
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
This PR adds documentation for the new `rootDir` setting (#27918), and for `next/no-html-link-for-pages`.
## Documentation / Examples
- [x] Make sure the linting passes
* Add a lint rule for using next script component when using inline script for Google Analytics.
* Apply suggestions from code review
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Update errors/next-script-for-ga.md
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Apply suggestions from code review
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Documentation:
- Expands the "Migrating Existing Config" section of ESLint doc to explain in more detail
- Minor changes to the "Ignoring ESLint" doc
Bug fixes:
- Adds `browser` and `node` environments to `eslint-config-next`. Closes#26319
- Fixes `no-document-import` rule. Closes#26159
- Fixes `no-page-custom-font` rule. Closes#26160#26894
This PR introduces an improved developer experience when `next lint` is run for the first time.
### Current behavior
`eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`:
Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues:
- Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`).
- #26348
- There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`.
- #26574
- #26475
- #26438
### New behavior
Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application.
<img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" />
- The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed
- Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`)
- For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config.
<img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png">
---
In addition, this PR also:
- Fixes#26348
- Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
Attempt to fix#26393
~~Sorry, I wasn't able to run tests on local, but I hope at least test should be valid.~~
Edit: Tests are working correctly on my local :)
fixes#26393
## Bug
- [x] Related issues linked using `fixes #26393`
- [x] Integration tests added
* add no-typos rule to eslint
* return early when function name is correct
* Handle null decl.type
* update check
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## 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
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' } `.
## 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
