fix(kit,nuxt): protect against resolved nuxt module subpath #33767
Conversation
|
|
WalkthroughModule installation now uses mlly.lookupNodeModuleSubpath to compute per-module subpaths and may set an installed module's entryPath to "name/subpath" when available; entryPath assignment in callModule was moved to an outer mutable variable and can fall back to the raw module string. Import-protection registration was moved into the modules:done hook and now builds patterns from nuxt.options._installedModules entries that have an entryPath instead of iterating string module names. Tests updated to use the new _installedModules shape. Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/kit/src/module/install.ts (1)
325-332: Consider error handling forlookupNodeModuleSubpath.The async
lookupNodeModuleSubpathcall could potentially fail or throw an error. Consider wrapping it in a try-catch block to handle failures gracefully, falling back to a default value.if (typeof modulePath === 'string') { const parsed = parseNodeModulePath(modulePath) if (parsed.name) { - const subpath = await lookupNodeModuleSubpath(modulePath) || '.' - entryPath = join(parsed.name, subpath === './' ? '.' : subpath) + try { + const subpath = await lookupNodeModuleSubpath(modulePath) || '.' + entryPath = join(parsed.name, subpath === './' ? '.' : subpath) + } catch { + // Fallback to package name if subpath lookup fails + entryPath = parsed.name + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/kit/src/module/install.ts(3 hunks)packages/nuxt/src/core/nuxt.ts(1 hunks)packages/nuxt/src/core/plugins/import-protection.ts(1 hunks)packages/nuxt/test/import-protection.test.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,vue}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Follow standard TypeScript conventions and best practices
Files:
packages/nuxt/src/core/plugins/import-protection.tspackages/kit/src/module/install.tspackages/nuxt/test/import-protection.test.tspackages/nuxt/src/core/nuxt.ts
**/*.{ts,tsx,js,jsx,vue}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx,js,jsx,vue}: Use clear, descriptive variable and function names
Add comments only to explain complex logic or non-obvious implementations
Keep functions focused and manageable (generally under 50 lines), and extract complex logic into separate domain-specific files
Remove code that is not used or needed
Use error handling patterns consistently
Files:
packages/nuxt/src/core/plugins/import-protection.tspackages/kit/src/module/install.tspackages/nuxt/test/import-protection.test.tspackages/nuxt/src/core/nuxt.ts
**/*.{test,spec}.{ts,tsx,js}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Write unit tests for core functionality using
vitest
Files:
packages/nuxt/test/import-protection.test.ts
🧠 Learnings (8)
📓 Common learnings
Learnt from: GalacticHypernova
Repo: nuxt/nuxt PR: 26468
File: packages/nuxt/src/components/plugins/loader.ts:24-24
Timestamp: 2024-11-05T15:22:54.759Z
Learning: In `packages/nuxt/src/components/plugins/loader.ts`, the references to `resolve` and `distDir` are legacy code from before Nuxt used the new unplugin VFS and will be removed.
Learnt from: huang-julien
Repo: nuxt/nuxt PR: 29366
File: packages/nuxt/src/app/components/nuxt-root.vue:16-19
Timestamp: 2024-12-12T12:36:34.871Z
Learning: In `packages/nuxt/src/app/components/nuxt-root.vue`, when optimizing bundle size by conditionally importing components based on route metadata, prefer using inline conditional imports like:
```js
const IsolatedPage = route?.meta?.isolate ? defineAsyncComponent(() => import('#build/isolated-page.mjs')) : null
```
instead of wrapping the import in a computed property or importing the component unconditionally.
📚 Learning: 2024-11-05T15:22:54.759Z
Learnt from: GalacticHypernova
Repo: nuxt/nuxt PR: 26468
File: packages/nuxt/src/components/plugins/loader.ts:24-24
Timestamp: 2024-11-05T15:22:54.759Z
Learning: In `packages/nuxt/src/components/plugins/loader.ts`, the references to `resolve` and `distDir` are legacy code from before Nuxt used the new unplugin VFS and will be removed.
Applied to files:
packages/nuxt/src/core/plugins/import-protection.tspackages/kit/src/module/install.tspackages/nuxt/test/import-protection.test.tspackages/nuxt/src/core/nuxt.ts
📚 Learning: 2024-12-12T12:36:34.871Z
Learnt from: huang-julien
Repo: nuxt/nuxt PR: 29366
File: packages/nuxt/src/app/components/nuxt-root.vue:16-19
Timestamp: 2024-12-12T12:36:34.871Z
Learning: In `packages/nuxt/src/app/components/nuxt-root.vue`, when optimizing bundle size by conditionally importing components based on route metadata, prefer using inline conditional imports like:
```js
const IsolatedPage = route?.meta?.isolate ? defineAsyncComponent(() => import('#build/isolated-page.mjs')) : null
```
instead of wrapping the import in a computed property or importing the component unconditionally.
Applied to files:
packages/nuxt/src/core/plugins/import-protection.tspackages/nuxt/test/import-protection.test.tspackages/nuxt/src/core/nuxt.ts
📚 Learning: 2024-11-28T21:22:40.496Z
Learnt from: GalacticHypernova
Repo: nuxt/nuxt PR: 29661
File: packages/kit/src/template.ts:227-229
Timestamp: 2024-11-28T21:22:40.496Z
Learning: In `packages/kit/src/template.ts`, when updating the `EXTENSION_RE` regular expression for TypeScript configuration, avoid using patterns like `(\.\w+)+$` as they can result in catastrophic backtracking.
Applied to files:
packages/nuxt/src/core/plugins/import-protection.ts
📚 Learning: 2025-11-25T11:42:16.119Z
Learnt from: CR
Repo: nuxt/nuxt PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T11:42:16.119Z
Learning: Applies to **/*.vue : Use `<script setup lang="ts">` and the composition API when creating Vue components
Applied to files:
packages/nuxt/test/import-protection.test.ts
📚 Learning: 2025-11-25T11:42:16.119Z
Learnt from: CR
Repo: nuxt/nuxt PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T11:42:16.119Z
Learning: Applies to **/*.{ts,tsx,vue} : Follow standard TypeScript conventions and best practices
Applied to files:
packages/nuxt/test/import-protection.test.ts
📚 Learning: 2025-11-25T11:42:16.119Z
Learnt from: CR
Repo: nuxt/nuxt PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T11:42:16.119Z
Learning: Applies to **/e2e/**/*.{ts,tsx,js} : Write end-to-end tests using Playwright and `nuxt/test-utils`
Applied to files:
packages/nuxt/test/import-protection.test.ts
📚 Learning: 2025-11-25T11:42:16.119Z
Learnt from: CR
Repo: nuxt/nuxt PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T11:42:16.119Z
Learning: Applies to **/*.{ts,tsx,js,jsx,vue} : Remove code that is not used or needed
Applied to files:
packages/nuxt/test/import-protection.test.ts
🪛 ast-grep (0.40.0)
packages/nuxt/src/core/plugins/import-protection.ts
[warning] 34-34: Regular expression constructed from variable input detected. This can lead to Regular Expression Denial of Service (ReDoS) attacks if the variable contains malicious patterns. Use libraries like 'recheck' to validate regex safety or use static patterns.
Context: new RegExp(^${escapeRE(mod.entryPath)}$)
Note: [CWE-1333] Inefficient Regular Expression Complexity [REFERENCES]
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
- https://cwe.mitre.org/data/definitions/1333.html
(regexp-from-variable)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build
- GitHub Check: code
🔇 Additional comments (7)
packages/nuxt/src/core/nuxt.ts (1)
372-395: LGTM! Timing change aligns with new entryPath-based protection.Moving import protection setup to the
modules:donehook ensures thatnuxt.options._installedModulesis fully populated before protection patterns are generated. This is necessary for the new entryPath-based approach.packages/nuxt/src/core/plugins/import-protection.ts (1)
32-39: LGTM! More precise module protection using resolved entry paths.The refactor from string-based module patterns to
entryPath-based patterns ensures that import protection rules match the actual resolved module locations. UsingescapeREto escape special regex characters prevents ReDoS vulnerabilities, making the static analysis warning a false positive.packages/nuxt/test/import-protection.test.ts (2)
25-25: LGTM! Test validates subpath imports are not blocked.This test case correctly verifies that importing from a module's runtime subpath (e.g.,
some-nuxt-module/runtime/something.vue) is not blocked when only the module's entry path (e.g.,some-nuxt-module) is protected. This confirms the fix described in the PR objectives.
48-51: LGTM! Test structure updated to match new module metadata format.The mock correctly uses
_installedModuleswithentryPathproperties, aligning with the refactored import protection logic.packages/kit/src/module/install.ts (3)
7-7: LGTM! New import for subpath resolution.The
lookupNodeModuleSubpathutility is needed to accurately determine the actual module entry path rather than relying on the string specified in the configuration.
328-330: Note: Performance implications of module subpath lookups.As mentioned in the PR description, the
lookupNodeModuleSubpathcall adds an async operation for each module installation. Consider investigating the performance impact and potentially optimising by caching results or tracking which subpath is used to avoid redundant lookups.
343-343: LGTM! Appropriate fallback for entryPath.The fallback correctly uses
moduleToInstallas theentryPathwhen the resolved path logic doesn't set it, which occurs whenmoduleToInstallis not a string or when module path parsing doesn't yield an entry path.
@nuxt/kit
@nuxt/nitro-server
nuxt
@nuxt/rspack-builder
@nuxt/schema
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #33767 will not alter performanceComparing Summary
|
🔗 Linked issue
📚 Description
in cases where we have a nuxt module as a subpath (e.g.
somelib/nuxt) it's nice - and intended! - to be able to specifysomelibin the module array in nuxt.config.however, this causes issues when there are imports from
somelibas these are caught by nuxt's import protection rules, designed to prevent modules from being imported in the nuxt appthis refactors how we generate those rules. instead of using the string array of modules in nuxt config, we use the actually installed module entry paths, using
mllyto 'lookup' the resolved path(I'd like to investigate performance of this - it would be better if we could track which subpath is being used to avoid the second lookup.... given we already have a list we search)