packages/nuxt/src/pages/route-rules.ts (2)

10-11: LGTM! TypeScript parsing support added correctly.

The imports are properly configured to enable TypeScript parsing capabilities.

Add a newline after the imports for better code organization:

 import * as acorn from 'acorn'
 import tsPlugin from 'acorn-typescript'
+
 const ROUTE_RULE_RE = /\bdefineRouteRules\(/

🧰 Tools

🪛 eslint (1.23.1)

[error] 11-11: Expected 1 empty line after import statement not followed by another import.

(import/newline-after-import)

---

Line range hint 29-45: Consider adding TypeScript-specific error messages.

While the implementation correctly handles TypeScript syntax, consider enhancing the error message to specifically mention TypeScript support when parsing fails. This would make debugging easier for users working with decorators and TypeScript syntax.

Example enhancement:

-            throw new Error('[nuxt] Error parsing route rules. They should be JSON-serializable.')
+            throw new Error('[nuxt] Error parsing route rules. Ensure the rules are JSON-serializable and TypeScript decorators are properly configured.')

packages/nuxt/src/core/plugins/prehydrate.ts (1)

25-28: Consider performance impact of TypeScript parsing

While the TypeScript parser integration is necessary, it might impact build performance. Consider adding a performance test comparing the old vs new implementation.

Would you like me to help create a performance benchmark for this change?

packages/nuxt/package.json (1)

74-74: Consider using fixed version for consistency with acorn.

While the added dependency is compatible with the current acorn version, consider using a fixed version for acorn-typescript to maintain consistency with how acorn is versioned in this package.

-    "acorn-typescript": "^1.4.13",
+    "acorn-typescript": "1.4.13",

packages/nuxt/src/core/plugins/plugin-metadata.ts (1)

Line range hint 78-80: Ensure consistent TypeScript parsing in all parsing instances

The RemovePluginMetadataPlugin is still using this.parse for code parsing. To maintain consistency and support TypeScript syntax throughout, consider updating the parser to use the extended TypeScript parser here as well.

Apply this diff to update the parsing method:

 try {
-  walk(this.parse(code, {
+  walk(acorn.Parser.extend(tsPlugin()).parse(code, {
     sourceType: 'module',
     ecmaVersion: 'latest',
   }) as Node, {

packages/nuxt/src/pages/utils.ts (2)

230-233: Type assertion 'as unknown as Program' may be too generic

Using as unknown as Program could mask potential type inconsistencies. Consider using a more precise type assertion to enhance type safety.

Apply this diff to improve the type assertion:

-}) as unknown as Program
+}) as Program

If the parse method returns an AST compatible with Program, this change ensures type correctness.

---

245-251: Inconsistent use of single and double quotes

The code uses both single (' ') and double (" ") quotes for strings. To adhere to the project's style guidelines and resolve the ESLint errors, please use single quotes consistently.

Apply the following diff to correct the quote usage:

-if ((node.type !== "ArrowFunctionExpression" && node.type !== 'ExpressionStatement')
+if ((node.type !== 'ArrowFunctionExpression' && node.type !== 'ExpressionStatement')

Repeat this change for lines 246 to 251 to address all instances:

-    || (node.body.type !== "CallExpression" && node.expression.type !== 'CallExpression')
+    || (node.body.type !== 'CallExpression' && node.expression.type !== 'CallExpression')
-    || (node.body.callee.type !== "Identifier" && node.expression.callee.type !== 'Identifier')
+    || (node.body.callee.type !== 'Identifier' && node.expression.callee.type !== 'Identifier')
-    || (node.body.callee.name !== "definePageMeta" && node.expression.callee.name !== 'definePageMeta')) { return }
+    || (node.body.callee.name !== 'definePageMeta' && node.expression.callee.name !== 'definePageMeta')) { return }

🧰 Tools

🪛 eslint (1.23.1)

[error] 245-245: Strings must use singlequote.

(@stylistic/quotes)

---

[error] 246-246: Strings must use singlequote.

(@stylistic/quotes)

---

[error] 247-247: Strings must use singlequote.

(@stylistic/quotes)

---

[error] 248-248: Strings must use singlequote.

(@stylistic/quotes)

---

[error] 251-251: Strings must use singlequote.

(@stylistic/quotes)

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for TypeScript-specific error handling cases in the codebase

# Search for TypeScript-specific test cases
rg -l "defineRouteRules.*@.*decorator" || echo "No TypeScript decorator tests found"

# Look for error handling patterns around defineRouteRules
rg "defineRouteRules.*try.*catch" -A 5

#!/bin/bash
# Let's verify the error handling implementation around the parser

# Check the implementation of error handling in the route-rules file
rg "walk.*acorn" -A 10 packages/nuxt/src/pages/route-rules.ts

# Look for test files related to route rules
fd "route-rules.test" -t f

# Check for any TypeScript-specific test files
fd "route-rules.*ts" -t f

# Look for any error handling patterns in the route rules implementation
rg "try.*catch.*walk" -A 10 packages/nuxt/src/pages/route-rules.ts

#!/bin/bash
# Let's check the broader context of the file to understand error handling

# Get the full content of route-rules.ts to see the complete implementation
cat packages/nuxt/src/pages/route-rules.ts

# Look for any test files that might test error cases
fd test -t f | rg -i "route|rules"

#!/bin/bash
# Search for Vue components using decorators in test files
rg -l "@Component|@Prop|@Watch|@Emit" --type ts

# Search for definePageMeta usage with decorators
rg -A 5 "definePageMeta.*@" --type ts

#!/bin/bash
# Let's analyze the actual usage of the parser in the codebase
ast-grep --pattern 'walk($$$)'

# Check for any TypeScript-specific syntax in the files being parsed
rg -A 5 "definePageMeta" --type ts

# Look for actual decorator usage in the codebase
rg -A 5 "@\w+" --type ts

# Check the test files to see if they cover TypeScript parsing
fd "test" -e ts -x cat {}

#!/bin/bash
# Description: Check latest versions and security advisories for acorn-typescript

# Check NPM for latest versions
echo "Latest version from NPM:"
curl -s https://registry.npmjs.org/acorn-typescript/latest | jq '.version'

# Check for security advisories
echo "Security advisories from GitHub:"
gh api graphql -f query='
{
  securityVulnerabilities(first: 5, ecosystem: NPM, package: "acorn-typescript") {
    nodes {
      advisory {
        summary
        severity
        publishedAt
      }
      vulnerableVersionRange
      firstPatchedVersion {
        identifier
      }
    }
  }
}'

packages/nuxt/src/core/plugins/plugin-metadata.ts (1)

51-54: Consider caching parsed AST for performance

While the current implementation works well, consider caching the parsed AST for frequently accessed plugins to improve performance, especially in development mode where plugins are parsed multiple times.

Example approach:

const astCache = new Map<string, Node>();

function getParsedAST(code: string) {
  if (astCache.has(code)) {
    return astCache.get(code);
  }
  const ast = acorn.Parser.extend(tsPlugin()).parse(code, {
    sourceType: 'module',
    ecmaVersion: 'latest',
    locations: true
  });
  astCache.set(code, ast);
  return ast;
}

Configuration used: CodeRabbit UI
Review profile: CHILL

packages/nuxt/src/pages/utils.ts (2)

230-234: Add error handling for parser initialization

While the TypeScript plugin integration is correct, consider adding error handling for parser initialization to gracefully handle potential plugin loading failures.

-    const ast = acorn.Parser.extend(tsPlugin()).parse(js.code, {
+    let parser;
+    try {
+      parser = acorn.Parser.extend(tsPlugin());
+    } catch (err) {
+      console.warn('[nuxt] Failed to initialize TypeScript parser:', err);
+      parser = acorn.Parser;
+    }
+    const ast = parser.parse(js.code, {
       sourceType: 'module',
       ecmaVersion: 'latest',
       locations: true,
       ranges: true,
     }) as unknown as Program

---

245-248: Improve readability of node type checking

The complex condition makes the code hard to maintain. Consider extracting the conditions into named functions for better readability.

+    function isArrowOrExpressionStatement(node: any): boolean {
+      return node.type === 'ArrowFunctionExpression' || node.type === 'ExpressionStatement';
+    }
+
+    function isDefinePageMetaCall(node: any): boolean {
+      const callExpr = node.body?.type === 'CallExpression' ? node.body : node.expression;
+      return callExpr?.type === 'CallExpression' &&
+             callExpr?.callee?.type === 'Identifier' &&
+             callExpr?.callee?.name === 'definePageMeta';
+    }
+
-        if ((node.type !== 'ArrowFunctionExpression' && node.type !== 'ExpressionStatement')
-             || (node.body.type !== 'CallExpression' && node.expression.type !== 'CallExpression')
-             || (node.body.callee.type !== 'Identifier' && node.expression.callee.type !== 'Identifier')
-             || (node.body.callee.name !== 'definePageMeta' && node.expression.callee.name !== 'definePageMeta')) { return }
+        if (!isArrowOrExpressionStatement(node) || !isDefinePageMetaCall(node)) { return }

Configuration used: CodeRabbit UI
Review profile: CHILL

packages/nuxt/src/pages/utils.ts (2)

230-233: Consider using a more type-safe approach for AST parsing.

While the TypeScript plugin integration is good, the double type assertion (unknown to Program) could be made more type-safe.

Consider this alternative:

-    const ast = acorn.Parser.extend(tsPlugin()).parse(js.code, {
+    const parser = acorn.Parser.extend(tsPlugin())
+    const ast = parser.parse(js.code, {
       sourceType: 'module',
       ecmaVersion: 'latest',
       locations: true,
       ranges: true,
-    }) as unknown as Program
+    }) as Program

---

245-248: Consider improving the readability of the node type checks.

While splitting the conditions improves readability, it could be further enhanced by extracting them into a helper function.

Consider this approach:

+        function isPageMetaCall(node: any, type: string, bodyPath: string[]): boolean {
+          if (node.type !== type) return false
+          let current: any = node
+          for (const prop of bodyPath) {
+            current = current[prop]
+            if (!current) return false
+          }
+          return current.type === 'Identifier' && current.name === 'definePageMeta'
+        }
+
-        const notExpressionStatement = node.type !== 'ExpressionStatement' || node.expression.type !== 'CallExpression' || node.expression.callee.type !== 'Identifier' || node.expression.callee.name !== 'definePageMeta'
-        const notArrowFunctionExpression = node.type !== 'ArrowFunctionExpression' || node.body.type !== 'CallExpression' || node.body.callee.type !== 'Identifier' || node.body.callee.name !== 'definePageMeta'
-
-        if (notExpressionStatement && notArrowFunctionExpression) { return }
+        const isValidExpression = isPageMetaCall(node, 'ExpressionStatement', ['expression', 'callee']) ||
+                                 isPageMetaCall(node, 'ArrowFunctionExpression', ['body', 'callee'])
+
+        if (!isValidExpression) { return }

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Search for files using decorators with definePageMeta
ast-grep --pattern 'class $_ {
  $$$
  @$_($$$)
  $$$
  definePageMeta($$$)
  $$$
}'

# Search for Vue components using vue-class-decorator
rg "@Component.*definePageMeta" -A 5

#!/bin/bash
# Let's try a different approach to verify decorator handling

# First, check if there are any TypeScript files with decorators in the test files
rg "@\w+" "test" -l --type ts

# Look for any existing decorator usage in the codebase
rg "@\w+" --type ts -l

# Check the test cases specifically testing the parser
fd "parser|utils.*test" -e ts -e js | xargs cat

# Look at the implementation to understand decorator handling
rg "tsPlugin|acorn.*parse" -A 5 -B 5