feat(nuxt,schema): experimentally normalise page component names to match route#33513
feat(nuxt,schema): experimentally normalise page component names to match route#33513
Conversation
|
|
@nuxt/kit
@nuxt/nitro-server
nuxt
@nuxt/rspack-builder
@nuxt/schema
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
Merging this PR will not alter performance
Comparing Footnotes
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Repository UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
WalkthroughAdds an experimental option 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
packages/nuxt/src/pages/utils.ts
Outdated
| : pageImport, | ||
| } | ||
|
|
||
| if (nuxt.options.experimental.normalizePageNames) { |
There was a problem hiding this comment.
could we maybe split this into normalizeComponent and normalizeComponentWithName functions, so we only assign it once, rather than manipulating an existing string?
There was a problem hiding this comment.
Do you mean a normalizeComponentName at runtime ?
There was a problem hiding this comment.
no. I mean, at the moment it's created a few lines above and then changed here
we can instead create it just once, which will tidy up the logic
# Conflicts: # packages/nuxt/src/pages/utils.ts # packages/nuxt/test/__snapshots__/pages-override-meta-enabled.test.ts.snap # packages/nuxt/test/pages.test.ts # test/bundle.test.ts
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/1.getting-started/18.upgrade.md`:
- Around line 1332-1342: Update the "What Changed" and "Migration Steps" text to
clarify this behavior is conditional: mention that page component names change
only when the opt-in flags are enabled (experimental.normalizePageNames or
future.compatibilityVersion: 5). Edit the "What Changed" paragraph and the
Migration Steps sentence to explicitly state the change applies only if
experimental.normalizePageNames is true or future.compatibilityVersion is set to
5, and advise users to enable that flag or check their compatibilityVersion
before updating KeepAlive include/exclude lists.
In `@docs/3.guide/6.going-further/1.experimental-features.md`:
- Line 618: The wording is ambiguous—replace the short key
"compatibilityVersion" with the fully-qualified config key
"future.compatibilityVersion" in the sentence that currently reads
"compatibilityVersion is set to 5 or higher" so the docs explicitly reference
future.compatibilityVersion and avoid confusion with similarly named options.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/1.getting-started/18.upgrade.mddocs/3.guide/6.going-further/1.experimental-features.md
# Conflicts: # docs/1.getting-started/18.upgrade.md
There was a problem hiding this comment.
♻️ Duplicate comments (2)
docs/3.guide/6.going-further/1.experimental-features.md (1)
618-618:⚠️ Potential issue | 🟡 MinorUse the fully-qualified config key in the default-behaviour sentence.
At Line 618,
compatibilityVersionis ambiguous; this should explicitly referencefuture.compatibilityVersion.Suggested fix
-This flag is enabled when `compatibilityVersion` is set to `5` or higher, but you can disable this feature: +This flag is enabled when `future.compatibilityVersion` is set to `5` or higher, but you can disable this feature:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/3.guide/6.going-further/1.experimental-features.md` at line 618, The sentence currently refers to `compatibilityVersion` ambiguously; update the default-behaviour sentence so it uses the fully-qualified config key `future.compatibilityVersion` instead of the short form, e.g., change "compatibilityVersion is set to 5 or higher" to "future.compatibilityVersion is set to 5 or higher" in the paragraph that starts with "This flag is enabled when ...".docs/1.getting-started/18.upgrade.md (1)
1384-1392:⚠️ Potential issue | 🟠 MajorScope this migration note to opt-in/compat mode.
At Lines 1384-1392, the text reads as unconditional, but this behaviour is conditional. Please state that it applies when
experimental.normalizePageNamesis enabled or whenfuture.compatibilityVersionis5.Suggested wording update
-Page component names now match their route names instead of using the filename. For example, `pages/foo/index.vue` will have the component name `foo` instead of `index`. +When `experimental.normalizePageNames` is enabled (or when `future.compatibilityVersion` is set to `5`), page component names match their route names instead of using the filename. For example, `pages/foo/index.vue` will have the component name `foo` instead of `index`. -If you rely on the current component names (e.g. in `<KeepAlive>` `include`/`exclude` lists), update them to use route names instead of filenames. +If you enable this behaviour and rely on current component names (e.g. in `<KeepAlive>` `include`/`exclude` lists), update them to use route names instead of filenames.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/1.getting-started/18.upgrade.md` around lines 1384 - 1392, Update the migration note titled "Page component names now match their route names..." to make the change conditional: state explicitly that this behavior only applies when experimental.normalizePageNames is enabled or when future.compatibilityVersion is set to 5 (compat mode). Replace the unconditional sentences in the "Reasons for Change" / "Migration Steps" block with wording that scopes the behavior to those config flags and add a short migration tip advising users to update <KeepAlive> include/exclude lists to use route names when opting into experimental.normalizePageNames or running in future.compatibilityVersion: 5.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/1.getting-started/18.upgrade.md`:
- Around line 1384-1392: Update the migration note titled "Page component names
now match their route names..." to make the change conditional: state explicitly
that this behavior only applies when experimental.normalizePageNames is enabled
or when future.compatibilityVersion is set to 5 (compat mode). Replace the
unconditional sentences in the "Reasons for Change" / "Migration Steps" block
with wording that scopes the behavior to those config flags and add a short
migration tip advising users to update <KeepAlive> include/exclude lists to use
route names when opting into experimental.normalizePageNames or running in
future.compatibilityVersion: 5.
In `@docs/3.guide/6.going-further/1.experimental-features.md`:
- Line 618: The sentence currently refers to `compatibilityVersion` ambiguously;
update the default-behaviour sentence so it uses the fully-qualified config key
`future.compatibilityVersion` instead of the short form, e.g., change
"compatibilityVersion is set to 5 or higher" to "future.compatibilityVersion is
set to 5 or higher" in the paragraph that starts with "This flag is enabled when
...".
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docs/1.getting-started/18.upgrade.mddocs/3.guide/6.going-further/1.experimental-features.mdpackages/schema/src/config/experimental.tspackages/schema/src/types/schema.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/schema/src/types/schema.ts
📚 Description
resolves #33254
this PR adds an experimental feature to normalize page components names using the route name.