fix(eslint): support pageExtensions in no-html-link-for-pages rule#92417
Open
Ankitajainkuniya wants to merge 1 commit intovercel:canaryfrom
Open
fix(eslint): support pageExtensions in no-html-link-for-pages rule#92417Ankitajainkuniya wants to merge 1 commit intovercel:canaryfrom
Ankitajainkuniya wants to merge 1 commit intovercel:canaryfrom
Conversation
Fixes vercel#53473 The `no-html-link-for-pages` ESLint rule hardcoded `.js(x)` and `.ts(x)` extensions when scanning for pages. Projects using custom `pageExtensions` (e.g., `.mdx`, `.md`) in `next.config.js` were not detected, so the rule would not warn about `<a>` links to those pages. Changes: - Added `pageExtensions` parameter to `parseUrlForPages` and `parseUrlForAppDir` - Created `buildExtensionRegex` helper for dynamic extension matching - Rule now reads `settings.next.pageExtensions` from ESLint config - Default behavior unchanged (falls back to tsx/ts/jsx/js) Usage in .eslintrc: ```json { "settings": { "next": { "pageExtensions": ["tsx", "ts", "jsx", "js", "mdx", "md"] } } } ```
Collaborator
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| /** | ||
| * Recursively parse app directory for URLs. | ||
| */ | ||
| function parseUrlForAppDir(urlprefix: string, directory: string) { |
Contributor
There was a problem hiding this comment.
Recursive calls in parseUrlForPages and parseUrlForAppDir do not pass the pageExtensions parameter, causing subdirectories to fall back to default extensions and miss pages with custom extensions like .mdx.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
settings.next.pageExtensionsin theno-html-link-for-pagesESLint rule.tsx/.ts/.jsx/.jsextensions when scanning pages/app directories, ignoring custompageExtensionsconfigured innext.config.jspageExtensionsfrom ESLint shared settings (context.settings.next?.pageExtensions) and passes them through the URL resolution pipelineChanges
packages/eslint-plugin-next/src/utils/url.ts: AddedbuildExtensionRegexhelper andpageExtensionsparameter toparseUrlForPages,parseUrlForAppDir,getUrlFromPagesDirectories, andgetUrlFromAppDirectorypackages/eslint-plugin-next/src/rules/no-html-link-for-pages.ts: Readscontext.settings.next?.pageExtensionsand passes it to URL utility functionsMotivation
Projects using custom
pageExtensions(e.g.,.page.tsx,.mdx) get false positives or missed warnings because the rule only looks for default extensions. This is consistent with how other Next.js ESLint rules already handlepageExtensions.Fixes #53473
Test Plan
pageExtensionsfrom ESLint settingspageExtensionssetting is provided