Skip to content

fix(nuxt): update nitropack preset directory#29780

Merged
danielroe merged 4 commits intomainfrom
fix/presets
Nov 4, 2024
Merged

fix(nuxt): update nitropack preset directory#29780
danielroe merged 4 commits intomainfrom
fix/presets

Conversation

@danielroe
Copy link
Member

@danielroe danielroe commented Nov 4, 2024

🔗 Linked issue

resolves #29777
resolves nitrojs/nitro#2846

📚 Description

this updates the preset directory for Nitro v2.10+.

Summary by CodeRabbit

  • New Features

    • Enhanced import protection rules to exclude the presets directory from module imports.
  • Bug Fixes

    • Improved regex pattern for better handling of module import patterns.

@bolt-new-by-stackblitz
Copy link

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 4, 2024

Walkthrough

The changes in this pull request involve an update to the regular expression within the createImportProtectionPatterns function in the import-protection.ts file. The modification adds the presets directory to the exclusion list, which prevents module imports from this directory during the build process. This adjustment aims to address issues related to the import of Nitro presets in server runtime environments.

Changes

File Path Change Summary
packages/nuxt/src/core/plugins/import-protection.ts Updated regex in createImportProtectionPatterns to exclude presets directory from imports.

Assessment against linked issues

Objective Addressed Explanation
Prevent imports from presets directory in server runtime (#2846, #29777)
Resolve build failure for node-cluster preset (#29777) Does not address all scenarios for build failures.

🐇 In the meadow, I hop and play,
New rules for imports brighten my day!
With presets now kept at bay,
No more errors, come what may!
Let's build with joy, hip-hip-hooray! 🎉


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 177d311 and c9fa055.

📒 Files selected for processing (1)
  • packages/nuxt/src/core/plugins/import-protection.ts (1 hunks)
🔇 Additional comments (1)
packages/nuxt/src/core/plugins/import-protection.ts (1)

39-41: LGTM! The regex modification correctly addresses the preset import issues.

The change to include presets in the negative lookahead assertion (?!(?:dist\/)?(?:presets|runtime|types)) appropriately allows imports from the Nitro presets directory while maintaining protection for other paths. This aligns with the PR objectives to fix build failures related to Nitro presets.

Let's verify the regex pattern matches the expected paths:

✅ Verification successful

The regex pattern correctly handles preset imports while maintaining protection

The verification confirms that the modified regex pattern works as intended:

  • ✓ Correctly allows imports from nitropack/dist/presets/* and nitropack/presets/*
  • ✓ Maintains existing allowances for runtime and types directories
  • ✓ Properly blocks imports from other nitropack paths like src and other
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the regex pattern correctly handles preset imports
# Test cases to validate the updated pattern

echo "Testing paths against pattern: /(^|node_modules\/)nitro(?:pack)?(?:-nightly)?(?:$|\/)(?!(?:dist\/)?(?:presets|runtime|types))/"

# These should NOT match (should be allowed)
echo "Should allow these paths:"
echo "nitropack/dist/presets/node-cluster" | grep -P "(^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" || echo "✓ Allows presets as expected"
echo "nitropack/presets/netlify" | grep -P "(^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" || echo "✓ Allows presets as expected"
echo "nitropack/dist/runtime/test" | grep -P "(^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" || echo "✓ Allows runtime as expected"

# These should match (should be blocked)
echo -e "\nShould block these paths:"
echo "nitropack/other/path" | grep -P "(^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" && echo "✓ Blocks other paths as expected"
echo "nitropack/src/something" | grep -P "(^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" && echo "✓ Blocks other paths as expected"

Length of output: 1471


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)
packages/nuxt/src/core/plugins/import-protection.ts (1)

39-39: Consider documenting the preset directory exception.

Since this modifies a core import protection pattern, it would be valuable to add a comment explaining why the presets directory needs to be excluded. This helps future maintainers understand the security implications and the rationale behind allowing these imports.

Consider adding a comment above the pattern:

+  // Allow imports from nitro presets directory (required for Nitro 2.10+)
   for (const i of [/(^|node_modules\/)@nuxt\/(kit|test-utils)/, ...
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 177d311 and c9fa055.

📒 Files selected for processing (1)
  • packages/nuxt/src/core/plugins/import-protection.ts (1 hunks)
🔇 Additional comments (1)
packages/nuxt/src/core/plugins/import-protection.ts (1)

39-39: LGTM! The regex modification correctly allows Nitro preset imports.

The updated pattern now properly excludes the presets directory from import protection, which aligns with the requirements for Nitro 2.10+ and should resolve the build issues with presets like "node-cluster".

Let's verify the fix addresses the reported issue:

✅ Verification successful

The regex pattern correctly handles Nitro preset imports

The verification test confirms that the import protection pattern works as intended:

  • ✅ Allows imports from nitro/dist/presets/* and nitropack/dist/presets/*
  • ✅ Allows existing permitted paths (dist/runtime/*, dist/types/*)
  • ✅ Blocks other Nitro paths as expected
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the regex pattern correctly handles Nitro preset imports
# Test cases:
# 1. Should allow: nitro/dist/presets/*
# 2. Should allow: nitropack/dist/presets/*
# 3. Should still block: other nitro paths

# Create test cases
cat << 'EOF' > test-imports.txt
import foo from 'nitro/dist/presets/node-cluster'
import bar from 'nitropack/dist/presets/custom'
import baz from 'nitro/something-else'
import qux from 'nitropack/other-path'
EOF

# Test the regex pattern
echo "Testing import protection pattern..."
rg -p '/(^|node_modules\/)nitro(?:pack)?(?:-nightly)?(?:$|\/)(?!(?:dist\/)?(?:presets|runtime|types))/' test-imports.txt

# Expected: Should match lines 3 and 4 (blocked imports)
# Should NOT match lines 1 and 2 (allowed preset imports)

Length of output: 389


Script:

#!/bin/bash
# Let's modify the regex pattern to work with ripgrep syntax
# Test cases for Nitro preset imports

# Create test cases
cat << 'EOF' > test-imports.txt
import foo from 'nitro/dist/presets/node-cluster'
import bar from 'nitropack/dist/presets/custom'
import baz from 'nitro/something-else'
import qux from 'nitropack/other-path'
EOF

# Test the regex pattern (modified for ripgrep compatibility)
echo "Testing import protection pattern..."
rg "(?:^|node_modules/)nitro(?:pack)?(?:-nightly)?(?:$|/)(?!(?:dist/)?(?:presets|runtime|types))" test-imports.txt

# Let's also check the actual implementation in the codebase
echo -e "\nChecking implementation in codebase:"
rg "nitro.*presets.*runtime.*types" packages/nuxt/src/core/plugins/import-protection.ts

Length of output: 970


Script:

#!/bin/bash
# Let's try a simpler approach to verify the pattern by checking individual paths
# Create test cases with full paths as they would appear in node_modules
cat << 'EOF' > test-imports.txt
/path/to/node_modules/nitro/dist/presets/node-cluster
/path/to/node_modules/nitropack/dist/presets/custom
/path/to/node_modules/nitro/something-else
/path/to/node_modules/nitropack/other-path
/path/to/node_modules/nitro/dist/runtime/test
/path/to/node_modules/nitro/dist/types/index
EOF

# Test each path separately with grep (which supports lookahead)
echo "Testing paths against protection pattern..."
while IFS= read -r line; do
  if echo "$line" | grep -E "^.*node_modules/nitro(pack)?(-nightly)?(/|$)" > /dev/null; then
    if ! echo "$line" | grep -E "dist/(presets|runtime|types)" > /dev/null; then
      echo "BLOCKED: $line"
    else
      echo "ALLOWED: $line"
    fi
  fi
done < test-imports.txt

Length of output: 2222

}

for (const i of [/(^|node_modules\/)@nuxt\/(kit|test-utils)/, /(^|node_modules\/)nuxi/, /(^|node_modules\/)nitro(?:pack)?(?:-nightly)?(?:$|\/)(?!(?:dist\/)?runtime|types)/, /(^|node_modules\/)nuxt\/(config|kit|schema)/]) {
for (const i of [/(^|node_modules\/)@nuxt\/(kit|test-utils)/, /(^|node_modules\/)nuxi/, /(^|node_modules\/)nitro(?:pack)?(?:-nightly)?(?:$|\/)(?!(?:dist\/)?(?:presets|runtime|types))/, /(^|node_modules\/)nuxt\/(config|kit|schema)/]) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better if we didn't depend on internal structure (even at cost of less import protection)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps nitro v3 would be a good time to revisit?

Copy link
Member

@pi0 pi0 Nov 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While there is a low chance for v2 to have major changes again, internal changes can always happen. I believe we should instead protect only known subpath patterns (nitropack / nitropack/kit are the main ones) + this logic should go into nitro itself for import protection (via unjs package).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's do it!

@HigherOrderLogic
Copy link
Contributor

This doesn't seem to solve the issue completely. See this action result.

If needed, I can try to make a minimal reproduction.

@yschroe
Copy link

yschroe commented Nov 6, 2024

Same problem here. I still get RollupError: [plugin impound] This module cannot be imported in server runtime. [importing node_modules/nitropack/node_modules/crossws/dist/adapters/node.mjs from node_modules/nitropack/dist/presets/_nitro/runtime/nitro-dev.mjs] in v3.14.159.

Can also work on a minimal repro if needed.

Edit: After deleting my lockfile, the node_modules folder and then reinstalling the dependencies again, I don't get this error anymore.

@they-cloned-me
Copy link

The issue with cloudflare-preset #29784 persists, unfortunately. 😞

Don't know if I should re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Some nitro presets fail to build with 3.14.0 netlify presets: [plugin impound] This module cannot be imported in server runtime

5 participants