feat: migrate to vue language tools v3 #80
Conversation
|
|
|
Warning Rate limit exceeded@so1ve has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 11 minutes and 49 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (47)
WalkthroughThe changes overhaul type printing and AST handling in the complex-types plugin, introducing robust helpers for AST traversal, node resolution, and script setup parsing. The Printer class now comprehensively prints TypeScript types, including references and declarations. Internal logic for defineProps and defineEmits transformations is refactored for accuracy. Test and build scripts are updated accordingly. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Plugin
participant Helpers
participant Printer
participant TS_AST
User->>Plugin: Triggers transformation (defineProps/defineEmits)
Plugin->>Helpers: Normalize path, get script setup block & AST
Helpers->>TS_AST: Retrieve AST nodes (type argument, identifiers)
Plugin->>Printer: Print type from AST node
Printer->>TS_AST: Resolve node kind, declarations, etc.
Printer-->>Plugin: Returns string representation
Plugin-->>User: Outputs transformed code
Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🔭 Outside diff range comments (1)
packages/language/src/index.ts (1)
90-110: Explicitly typelanguageor specify the generic parameter instead ofas any.Instead of masking the mismatch with
as any, you can:• Import and apply the Vue‐language‐core
Languagetypeimport type { Language as VueLanguage } from "@vue/language-core"; // annotate your `language` value const language: VueLanguage<string> = vue.createLanguage( [vueLanguagePlugin, { getLanguageId: … }], new vue.FileMap(ts.sys.useCaseSensitiveFileNames), /* … */ );• Or constrain
createLanguageServiceHostby passing its generic argument:- const { languageServiceHost } = createLanguageServiceHost( + const { languageServiceHost } = createLanguageServiceHost<string>( ts, ts.sys, language, (s) => s, projectHost, );Either approach preserves full type safety without resorting to
any.
🧹 Nitpick comments (3)
packages/language/src/helpers.ts (2)
61-78: Consider early termination for better performance.The function correctly finds nodes by range, but continues traversing even after finding a match.
function findNodeByRange( ast: ts.SourceFile, filter: (ranges: vue.ScriptSetupRanges) => vue.TextRange | undefined, ): ts.Node | undefined { const scriptSetupRanges = parseScriptSetupRanges(ast); const range = filter(scriptSetupRanges); if (!range) { return; } let node: ts.Node | undefined; - traverseAst(ast, (n) => { + ts.forEachChild(ast, function traverse(n: ts.Node): boolean | undefined { if (n.getStart(ast) === range.start && n.getEnd() === range.end) { node = n; + return true; // Stop traversal } + return ts.forEachChild(n, traverse); }); return node; }
80-92: Consider early termination and be aware of multiple matches.The function finds the first identifier with the given name but continues traversing. Also note that it returns the first match, which might not always be the intended one if multiple identifiers share the same name.
function findNodeByName( ast: ts.SourceFile, name: string, ): ts.Node | undefined { let node: ts.Node | undefined; - traverseAst(ast, (n) => { + ts.forEachChild(ast, function traverse(n: ts.Node): boolean | undefined { if (ts.isIdentifier(n) && n.getText(ast) === name) { node = n; + return true; // Stop traversal } + return ts.forEachChild(n, traverse); }); return node; }packages/complex-types/src/core/printer.ts (1)
382-432: Consider using a map or switch for better performance.The extensive if-else chain works correctly but could be optimized.
Consider refactoring to use a map of node type handlers:
private nodeHandlers = new Map<ts.SyntaxKind, (node: any) => string>([ [ts.SyntaxKind.IntersectionType, (n) => this.printIntersectionTypeNode(n)], [ts.SyntaxKind.UnionType, (n) => this.printUnionTypeNode(n)], // ... other handlers ]); public printType(node: ts.Node): string { const handler = this.nodeHandlers.get(node.kind); if (handler) { return handler(node); } // Handle remaining cases... }The current implementation is comprehensive and handles all major TypeScript node types correctly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
packages/complex-types/test/__snapshots__/fixtures-compiled.test.ts.snapis excluded by!**/*.snappackages/complex-types/test/__snapshots__/fixtures.test.ts.snapis excluded by!**/*.snappackages/tsx-auto-props/test/__snapshots__/fixtures.test.ts.snapis excluded by!**/*.snappnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
package.json(1 hunks)packages/complex-types/src/core/printer.ts(2 hunks)packages/complex-types/src/core/transformers/defineEmits.ts(2 hunks)packages/complex-types/src/core/transformers/defineProps.ts(1 hunks)packages/complex-types/src/core/utils.ts(0 hunks)packages/complex-types/test/fixtures-compiled.test.ts(2 hunks)packages/language/src/helpers.ts(1 hunks)packages/language/src/index.ts(4 hunks)packages/tsx-auto-props/src/core/transform.ts(2 hunks)
💤 Files with no reviewable changes (1)
- packages/complex-types/src/core/utils.ts
🧰 Additional context used
🧬 Code Graph Analysis (4)
packages/complex-types/src/core/transformers/defineProps.ts (3)
packages/complex-types/src/core/types.ts (1)
Transformer(16-20)packages/common/src/utils.ts (1)
normalizePath(2-2)packages/language/src/index.ts (1)
getLanguage(163-169)
packages/tsx-auto-props/src/core/transform.ts (3)
packages/common/src/utils.ts (1)
normalizePath(2-2)packages/language/src/index.ts (1)
getLanguage(163-169)packages/tsx-auto-props/src/core/utils.ts (1)
getNodeAssignNode(13-32)
packages/language/src/index.ts (2)
packages/common/src/utils.ts (1)
normalizePath(2-2)packages/language/src/helpers.ts (1)
createHelpers(4-103)
packages/complex-types/src/core/transformers/defineEmits.ts (3)
packages/complex-types/src/core/types.ts (1)
Transformer(16-20)packages/common/src/utils.ts (1)
normalizePath(2-2)packages/language/src/index.ts (1)
getLanguage(163-169)
🔇 Additional comments (18)
packages/complex-types/test/fixtures-compiled.test.ts (1)
29-30: Good type safety improvement and build tool migrationThe removal of
as anytype assertion improves type safety. The migration from esbuild to Oxc aligns with modern tooling trends.Consider documenting the rationale for migrating from esbuild to Oxc in the PR description or commit message for future reference.
packages/complex-types/src/core/transformers/defineProps.ts (1)
7-24: Improved error handling and AST retrieval logicThe addition of early returns for missing AST components and the structured approach to retrieving script setup blocks improves robustness. The change to use
__VLS_Propsfrom the virtual file AST aligns with Vue Language Tools v3 architecture.packages/tsx-auto-props/src/core/transform.ts (2)
21-26: Good defensive programming with early returnThe addition of the early return when AST is not found prevents potential runtime errors. The clarifying comment about .tsx files is also helpful.
34-39: Correct API usage for TypeScript 5.xThe change from
.escapedTextto.textis correct for accessing property names in newer TypeScript versions.packages/complex-types/src/core/transformers/defineEmits.ts (2)
8-27: Consistent refactoring pattern with defineProps.tsThe refactoring follows the same improved pattern as
defineProps.tswith proper error handling, structured AST retrieval, and use of virtual file AST nodes. This consistency is good for maintainability.
67-69: Updated method name for printing eventsThe change from
printTypetoprintEventsRuntimeArgis more specific and indicates specialized handling for emit events.packages/language/src/helpers.ts (5)
4-12: LGTM! Well-structured factory function.The
createHelpersfunction properly encapsulates helper utilities with appropriate dependencies. TheparseScriptSetupRangesimplementation correctly delegates to Vue's parser.
13-28: Good defensive programming with proper guard clauses.The function correctly validates the source file type, checks for script setup existence, and restricts to TypeScript languages only.
30-52: Efficient AST retrieval with proper fallback handling.Both functions handle edge cases well. The
getVirtualFileOrTsAstfunction's fallback mechanism to append language extensions for virtual files is a clever approach for Vue's virtual file system.
54-59: Clean AST traversal implementation.The recursive traversal using
ts.forEachChildis the standard approach for TypeScript AST traversal.
94-103: Well-organized helper exports.All helper functions are properly exposed through the returned object.
packages/language/src/index.ts (4)
4-13: Clean import organization with new helper module.The imports are well-organized, properly bringing in the new
createHelpersfunction and necessary types from @volar/typescript.
17-28: Simplified API with direct parsed command line creation.The removal of
configFileNameparameter and direct usage ofvue.createParsedCommandLinesimplifies the API while maintaining functionality.
35-48: Efficient file management with Set and normalized paths.Great improvements:
- Using
SetforfileNamesprovides O(1) add/delete operations- Path normalization ensures consistency across different OS platforms
- Simplified
projectHostreduces complexity
115-152: Excellent helper integration and file management methods.The new methods provide comprehensive file management capabilities:
- Consistent path normalization across all methods
- Proper cache invalidation with version incrementing
- Clean integration of helper functions
packages/complex-types/src/core/printer.ts (3)
20-26: Consistent type printing for intersection and union types.Good refactoring to use the new
printTypemethod for consistent handling of nested types.
145-283: Well-structured class and interface printing methods.Both methods comprehensively handle their respective member types with proper null safety and type resolution.
285-347: Comprehensive function and array type printing.Excellent handling of:
- Optional and rest parameters in function types
- Named tuple members with proper syntax
- Array type notation
| "release": "bumpp package.json packages/*/package.json --commit --push --tag && pnpm publish -r --filter ./packages/*", | ||
| "test": "vitest", | ||
| "typecheck": "tsc --noEmit" | ||
| "typecheck": "tsgo --noEmit" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the tsgo command exists and is intended
The typecheck script was changed from tsc --noEmit to tsgo --noEmit. The command tsgo is not a standard TypeScript compiler command. This appears to be a typo or missing dependency.
🏁 Script executed:
#!/bin/bash
# Check if tsgo is a valid command or package
# Search for tsgo in package.json dependencies
cat package.json | jq '.dependencies, .devDependencies' | grep -i tsgo
# Search for any tsgo-related files or imports in the codebase
rg -i "tsgo" --type json --type ts --type js
# Check if this might be a typo for 'tsc'
fd -e json -e ts -e js | xargs grep -l "tsgo"Length of output: 220
🏁 Script executed:
#!/bin/bash
# Verify if 'tsgo' and '@typescript/native-preview' are published on npm
npm view tsgo version || echo "tsgo not found on npm"
npm view @typescript/native-preview version || echo "@typescript/native-preview not found on npm"Length of output: 536
Invalid typecheck command: tsgo is not a published package
- package.json (line 13):
- Current:
"typecheck": "tsgo --noEmit" - Issue:
tsgodoes not exist on npm (E404). This is likely a typo for the standard TypeScript compiler command. - Suggestion: change to
- "typecheck": "tsgo --noEmit" + "typecheck": "tsc --noEmit"
- Current:
- Dev dependency
@typescript/[email protected]: this is a preview build and may introduce instability. Confirm that a preview release is acceptable for your CI/type-checking pipeline or consider using a stable TypeScript version instead.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "typecheck": "tsgo --noEmit" | |
| "typecheck": "tsc --noEmit" |
🤖 Prompt for AI Agents
In package.json at line 13, the "typecheck" script uses "tsgo --noEmit", which
is an invalid command because "tsgo" is not a published package. Replace "tsgo"
with the correct TypeScript compiler command "tsc" to fix the script. Also,
review the use of the preview version of @typescript/native-preview in dev
dependencies and consider switching to a stable TypeScript version if stability
is a concern.
| "@so1ve/eslint-config": "^3.7.0", | ||
| "@so1ve/prettier-config": "^3.7.0", | ||
| "@types/node": "^24.0.13", | ||
| "@typescript/native-preview": "7.0.0-dev.20250711.1", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Consider the stability implications of using a dev preview package
The addition of @typescript/native-preview at version 7.0.0-dev.20250711.1 is a development preview that may have stability issues or breaking changes.
🌐 Web query:
What is @typescript/native-preview package and is version 7.0.0-dev.20250711.1 stable for production use?
💡 Result:
The @typescript/native-preview package is a preview build of the native TypeScript compiler and toolset, ported from JavaScript to Go, aimed at delivering significantly faster build times and lower memory usage compared to the traditional Node.js-based TypeScript compiler[1][3][6]. It provides a new executable, tsgo, which works similarly to tsc and is designed for use in testing and experimentation while development proceeds toward full feature parity and stability[1][2][5][6].
As of mid-2025, @typescript/native-preview remains in an early, experimental state. The project’s maintainers, including the TypeScript team at Microsoft, repeatedly emphasize that this package:
- Is intended for testing and experimentation only
- Lacks full feature parity with the canonical TypeScript toolchain (some features are missing or only partially implemented; see the GitHub status table for details[2])
- Is not recommended for production use at this time[5]
"This package is intended for testing and experimentation. It will eventually be replaced by the official TypeScript package... The native port of TypeScript is still in progress. We expect many gaps..."[5]
The 7.0.0-dev.20250711.1 version is a development/nightly build, as indicated by the dev tag and date. Nightly or -dev versions are inherently unstable and may contain regressions, incomplete features, or breaking changes by design[4][5]. Stable production use is only advisable when the TypeScript team explicitly announces general availability and removes the preview/dev labels.
In summary:
@typescript/native-preview is a preview, not stable, package. Version 7.0.0-dev.20250711.1 is not stable or recommended for production use; it is for early adopters and testers only. For production deployments, continue to use the official typescript package until a formal stable release is announced[1][5].
Citations:
- 1: https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/
- 2: https://github.com/microsoft/typescript-go
- 3: https://socket.dev/blog/typescript-native-previews-now-on-npm-for-public-testing
- 4: https://marketplace.visualstudio.com/items?itemName=TypeScriptTeam.native-preview
- 5: https://www.npmjs.com/package/@typescript/native-preview
- 6: https://www.infoq.com/news/2025/05/new-typescript-compiler-10x-fast/
Avoid using the experimental @typescript/native-preview in production
The 7.0.0-dev.20250711.1 build is an early, feature-incomplete preview ported to Go and is not recommended for production use. For stable, fully supported compilations, switch to the official typescript package—or at minimum move this preview into devDependencies and pin a stable TypeScript release for your production builds.
- package.json (dependencies, around line 20)
Suggested change:
- "@typescript/native-preview": "7.0.0-dev.20250711.1",
+ "typescript": "^5.x" // use the official stable TypeScript compilerOptionally, if you still need to experiment with @typescript/native-preview:
- (in "dependencies")
+ (move to "devDependencies")
"@typescript/native-preview": "7.0.0-dev.20250711.1",Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In package.json at line 20, the dependency "@typescript/native-preview" is an
experimental and unstable package not suitable for production. To fix this, move
"@typescript/native-preview" from "dependencies" to "devDependencies" and add
the stable "typescript" package version to "dependencies" to ensure production
builds use a stable TypeScript release.
| @@ -1,3 +1,4 @@ | |||
| import { normalizePath } from "@vue.ts/common"; | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Inconsistent import source for normalizePath
This file imports normalizePath from @vue.ts/common while defineProps.ts imports it from 'vite'. Consider standardizing the import source across the codebase.
-import { normalizePath } from "@vue.ts/common";
+import { normalizePath } from "vite";Or update both files to use the same source.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { normalizePath } from "@vue.ts/common"; | |
| import { normalizePath } from "vite"; |
🤖 Prompt for AI Agents
In packages/tsx-auto-props/src/core/transform.ts at line 1, the import source
for normalizePath is inconsistent with other files like defineProps.ts which
import it from 'vite'. To fix this, standardize the import source by changing
the import statement to match the one used in defineProps.ts, importing
normalizePath from 'vite' instead of '@vue.ts/common'. Ensure both files use the
same source for consistency across the codebase.
| @@ -1,46 +1,44 @@ | |||
| import { normalizePath } from "@vue.ts/common"; | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Another inconsistent import source for normalizePath
This file imports normalizePath from @vue.ts/common, while other files use different sources. This inconsistency should be resolved.
🏁 Script executed:
#!/bin/bash
# Find all normalizePath imports to show the inconsistency
rg "import.*normalizePath" --type ts -A 1 -B 1
# Check which normalizePath implementations exist
fd -e ts | xargs rg "export.*normalizePath.*=" -A 2Length of output: 1127
Unify normalizePath import source across packages
While most files import normalizePath from @vue.ts/common, defineProps.ts still pulls it from vite. To maintain consistency and avoid multiple utility implementations, please consolidate all imports to a single source. We recommend using the shared implementation in packages/common.
Files needing update:
packages/complex-types/src/core/transformers/defineProps.ts
Suggested change in defineProps.ts:
-import { normalizePath } from "vite";
+import { normalizePath } from "@vue.ts/common";Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/complex-types/src/core/transformers/defineProps.ts at the import
statements, change the source of the normalizePath import from 'vite' to
'@vue.ts/common' to unify the import source across packages and avoid multiple
utility implementations.
| const vueLanguagePlugin = vue.createVueLanguagePlugin<string>( | ||
| ts, | ||
| projectHost.getCompilationSettings(), | ||
| parsedCommandLine.vueOptions, | ||
| (id) => id, | ||
| ); | ||
|
|
||
| const language = vue.createLanguage( | ||
| [ | ||
| vueLanguagePlugin, | ||
| { | ||
| getLanguageId(fileName) { | ||
| return resolveFileLanguageId(fileName); | ||
| }, | ||
| }, | ||
| ], | ||
| new vue.FileMap(ts.sys.useCaseSensitiveFileNames), | ||
| (fileName) => { | ||
| if (ts.sys.useCaseSensitiveFileNames) { | ||
| return host.getScriptFileNames().includes(fileName) ?? false; | ||
| } else { | ||
| const lowerFileName = fileName.toLowerCase(); | ||
| for (const rootFile of host.getScriptFileNames()) { | ||
| if (rootFile.toLowerCase() === lowerFileName) { | ||
| return true; | ||
| } | ||
| let snapshot = scriptSnapshots.get(fileName); | ||
|
|
||
| if (!scriptSnapshots.has(fileName)) { | ||
| const fileText = ts.sys.readFile(fileName); | ||
| if (fileText) { | ||
| scriptSnapshots.set(fileName, ts.ScriptSnapshot.fromString(fileText)); | ||
| } else { | ||
| scriptSnapshots.set(fileName, undefined); | ||
| } | ||
| } | ||
|
|
||
| return false; | ||
| snapshot = scriptSnapshots.get(fileName); | ||
|
|
||
| if (snapshot) { | ||
| language.scripts.set(fileName, snapshot); | ||
| } else { | ||
| language.scripts.delete(fileName); | ||
| } | ||
| }, | ||
| host.getCompilationSettings(), | ||
| vueCompilerOptions, | ||
| ); |
There was a problem hiding this comment.
Missing return value in snapshot getter function.
The snapshot getter function doesn't return a value, which might be required by the language API.
(fileName) => {
let snapshot = scriptSnapshots.get(fileName);
if (!scriptSnapshots.has(fileName)) {
const fileText = ts.sys.readFile(fileName);
if (fileText) {
scriptSnapshots.set(fileName, ts.ScriptSnapshot.fromString(fileText));
} else {
scriptSnapshots.set(fileName, undefined);
}
}
snapshot = scriptSnapshots.get(fileName);
if (snapshot) {
language.scripts.set(fileName, snapshot);
} else {
language.scripts.delete(fileName);
}
+
+ return snapshot;
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const vueLanguagePlugin = vue.createVueLanguagePlugin<string>( | |
| ts, | |
| projectHost.getCompilationSettings(), | |
| parsedCommandLine.vueOptions, | |
| (id) => id, | |
| ); | |
| const language = vue.createLanguage( | |
| [ | |
| vueLanguagePlugin, | |
| { | |
| getLanguageId(fileName) { | |
| return resolveFileLanguageId(fileName); | |
| }, | |
| }, | |
| ], | |
| new vue.FileMap(ts.sys.useCaseSensitiveFileNames), | |
| (fileName) => { | |
| if (ts.sys.useCaseSensitiveFileNames) { | |
| return host.getScriptFileNames().includes(fileName) ?? false; | |
| } else { | |
| const lowerFileName = fileName.toLowerCase(); | |
| for (const rootFile of host.getScriptFileNames()) { | |
| if (rootFile.toLowerCase() === lowerFileName) { | |
| return true; | |
| } | |
| let snapshot = scriptSnapshots.get(fileName); | |
| if (!scriptSnapshots.has(fileName)) { | |
| const fileText = ts.sys.readFile(fileName); | |
| if (fileText) { | |
| scriptSnapshots.set(fileName, ts.ScriptSnapshot.fromString(fileText)); | |
| } else { | |
| scriptSnapshots.set(fileName, undefined); | |
| } | |
| } | |
| return false; | |
| snapshot = scriptSnapshots.get(fileName); | |
| if (snapshot) { | |
| language.scripts.set(fileName, snapshot); | |
| } else { | |
| language.scripts.delete(fileName); | |
| } | |
| }, | |
| host.getCompilationSettings(), | |
| vueCompilerOptions, | |
| ); | |
| (fileName) => { | |
| let snapshot = scriptSnapshots.get(fileName); | |
| if (!scriptSnapshots.has(fileName)) { | |
| const fileText = ts.sys.readFile(fileName); | |
| if (fileText) { | |
| scriptSnapshots.set(fileName, ts.ScriptSnapshot.fromString(fileText)); | |
| } else { | |
| scriptSnapshots.set(fileName, undefined); | |
| } | |
| } | |
| snapshot = scriptSnapshots.get(fileName); | |
| if (snapshot) { | |
| language.scripts.set(fileName, snapshot); | |
| } else { | |
| language.scripts.delete(fileName); | |
| } | |
| return snapshot; | |
| }, |
🤖 Prompt for AI Agents
In packages/language/src/index.ts between lines 51 and 88, the snapshot getter
function does not return any value, but the language API likely expects it to
return the snapshot. Modify the function to return the snapshot after setting or
deleting it in the language.scripts map, ensuring the function returns the
snapshot or undefined as appropriate.
There was a problem hiding this comment.
Actionable comments posted: 8
🔭 Outside diff range comments (1)
packages/complex-types/package.json (1)
1-121: Update pnpm lockfile to reflect dependency changes.The pipeline is failing because
unbuildwas removed from devDependencies but the pnpm-lock.yaml wasn't updated.Run the following command to update the lockfile:
pnpm install --no-frozen-lockfile
♻️ Duplicate comments (1)
packages/language/src/index.ts (1)
68-88: Missing return value in snapshot getter function.The snapshot getter function doesn't return a value, which is likely required by the language API. This matches the concern raised in the past review comment.
(fileName) => { let snapshot = scriptSnapshots.get(fileName); if (!scriptSnapshots.has(fileName)) { const fileText = ts.sys.readFile(fileName); if (fileText) { scriptSnapshots.set(fileName, ts.ScriptSnapshot.fromString(fileText)); } else { scriptSnapshots.set(fileName, undefined); } } snapshot = scriptSnapshots.get(fileName); if (snapshot) { language.scripts.set(fileName, snapshot); } else { language.scripts.delete(fileName); } + + return snapshot; },
🧹 Nitpick comments (2)
packages/common/package.json (1)
19-21: Consider dual export for CJS consumersBy collapsing the
"exports"map to a single ESM entry you drop CommonJS support.
If that is intended, great. Otherwise, add arequirecondition pointing to a transpiled.cjs, or clearly document the breaking change in the changelog.No action required if full ESM-only is the goal.
packages/language/src/index.ts (1)
20-20: Return type annotation could be more specific.The return type
ReturnType<typeof createLanguageWorker>is correct but could be more explicit. Consider using the newly definedLanguagetype alias for better readability.-): ReturnType<typeof createLanguageWorker> { +): Language {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (40)
package.json(1 hunks)packages/common/build.config.ts(0 hunks)packages/common/package.json(2 hunks)packages/common/tsdown.config.ts(1 hunks)packages/complex-types/build.config.ts(0 hunks)packages/complex-types/package.json(4 hunks)packages/complex-types/src/astro.ts(1 hunks)packages/complex-types/src/esbuild.ts(1 hunks)packages/complex-types/src/farm.ts(1 hunks)packages/complex-types/src/index.ts(1 hunks)packages/complex-types/src/nuxt.ts(1 hunks)packages/complex-types/src/rolldown.ts(1 hunks)packages/complex-types/src/rollup.ts(1 hunks)packages/complex-types/src/rspack.ts(1 hunks)packages/complex-types/src/vite.ts(1 hunks)packages/complex-types/src/webpack.ts(1 hunks)packages/complex-types/tsdown.config.ts(1 hunks)packages/language/build.config.ts(0 hunks)packages/language/package.json(2 hunks)packages/language/src/index.ts(3 hunks)packages/language/tsdown.config.ts(1 hunks)packages/tsx-auto-props/build.config.ts(0 hunks)packages/tsx-auto-props/package.json(4 hunks)packages/tsx-auto-props/src/astro.ts(1 hunks)packages/tsx-auto-props/src/core/index.ts(0 hunks)packages/tsx-auto-props/src/core/types.ts(0 hunks)packages/tsx-auto-props/src/core/utils.ts(1 hunks)packages/tsx-auto-props/src/esbuild.ts(1 hunks)packages/tsx-auto-props/src/farm.ts(1 hunks)packages/tsx-auto-props/src/index.ts(1 hunks)packages/tsx-auto-props/src/nuxt.ts(1 hunks)packages/tsx-auto-props/src/rolldown.ts(1 hunks)packages/tsx-auto-props/src/rollup.ts(1 hunks)packages/tsx-auto-props/src/rspack.ts(1 hunks)packages/tsx-auto-props/src/types.ts(1 hunks)packages/tsx-auto-props/src/vite.ts(1 hunks)packages/tsx-auto-props/src/webpack.ts(1 hunks)packages/tsx-auto-props/tsdown.config.ts(1 hunks)tsconfig.json(1 hunks)tsdown.config.ts(1 hunks)
💤 Files with no reviewable changes (6)
- packages/language/build.config.ts
- packages/tsx-auto-props/build.config.ts
- packages/complex-types/build.config.ts
- packages/common/build.config.ts
- packages/tsx-auto-props/src/core/types.ts
- packages/tsx-auto-props/src/core/index.ts
✅ Files skipped from review due to trivial changes (10)
- packages/tsx-auto-props/src/core/utils.ts
- packages/complex-types/src/farm.ts
- packages/language/tsdown.config.ts
- packages/common/tsdown.config.ts
- packages/tsx-auto-props/src/rolldown.ts
- packages/tsx-auto-props/tsdown.config.ts
- tsdown.config.ts
- packages/complex-types/src/rolldown.ts
- packages/complex-types/tsdown.config.ts
- packages/tsx-auto-props/src/farm.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
🧰 Additional context used
🧬 Code Graph Analysis (10)
packages/tsx-auto-props/src/webpack.ts (1)
packages/tsx-auto-props/src/index.ts (1)
unpluginFactory(10-31)
packages/tsx-auto-props/src/rollup.ts (1)
packages/tsx-auto-props/src/index.ts (1)
unpluginFactory(10-31)
packages/tsx-auto-props/src/esbuild.ts (1)
packages/tsx-auto-props/src/index.ts (1)
unpluginFactory(10-31)
packages/tsx-auto-props/src/vite.ts (1)
packages/tsx-auto-props/src/index.ts (1)
unpluginFactory(10-31)
packages/complex-types/src/webpack.ts (1)
packages/complex-types/src/index.ts (1)
unpluginFactory(10-31)
packages/complex-types/src/esbuild.ts (1)
packages/complex-types/src/index.ts (1)
unpluginFactory(10-31)
packages/tsx-auto-props/src/types.ts (1)
packages/common/src/types.ts (1)
BaseOptions(3-6)
packages/complex-types/src/nuxt.ts (3)
packages/tsx-auto-props/src/types.ts (1)
Options(3-5)packages/complex-types/src/core/types.ts (1)
Options(8-11)packages/complex-types/src/astro.ts (1)
options(6-16)
packages/language/src/index.ts (2)
packages/common/src/utils.ts (1)
normalizePath(2-2)packages/language/src/helpers.ts (1)
createHelpers(4-103)
packages/tsx-auto-props/src/nuxt.ts (1)
packages/tsx-auto-props/src/types.ts (1)
Options(3-5)
🪛 GitHub Actions: CI
packages/complex-types/package.json
[error] 1-1: pnpm install failed due to outdated lockfile. The pnpm-lock.yaml is not up to date with package.json. Dependency 'unbuild@^3.5.0' was removed from package.json but not reflected in the lockfile. Run 'pnpm install --no-frozen-lockfile' to update the lockfile.
⏰ 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). (1)
- GitHub Check: autofix
🔇 Additional comments (41)
packages/tsx-auto-props/src/types.ts (1)
1-7: LGTM! Well-structured type definitions.The explicit type declarations are clean and follow TypeScript best practices. The separation from re-exports to explicit definitions improves maintainability, and the use of
Required<Options>forResolvedOptionsis a good pattern for ensuring all options are present after resolution.tsconfig.json (2)
10-10: Good addition for TypeScript extension imports.The
allowImportingTsExtensionsoption is helpful for bundler environments where TypeScript files can be imported directly with their extensions, supporting the ESM migration.
8-8: Bundler resolution is fully supported across the toolchainAll core dependencies in package.json—TypeScript v5.8.3, Vite v7.0.4, vite-tsconfig-paths v5.1.4, and Vitest v3.2.4—officially support
moduleResolution: "Bundler". The isolated test fixtures inpackages/complex-typesstill use"Node", but they are self-contained and won’t be affected by the root tsconfig change. No further action is required; approving the ESM migration configuration.packages/tsx-auto-props/src/astro.ts (2)
9-9: Consistent with plugin factory pattern.The usage change from
unplugin.vite(options)tovite(options)is consistent with the broader refactoring to factory-based plugin creation across the package.
2-2: Verification complete:viteimport is valid and correctly typed.
packages/tsx-auto-props/src/vite.tsexports a default value fromcreateVitePlugin(unpluginFactory), which is a function.- Calling
vite(options)inastro.tsmatches the expected plugin-factory signature.packages/tsx-auto-props/src/webpack.ts (1)
1-5: Excellent simplification of the webpack plugin export.The refactoring from importing the entire unplugin instance and casting its webpack property to using
createWebpackPluginwithunpluginFactoryis much cleaner. This removes TypeScript workarounds and aligns with the standardized plugin creation pattern across the package.packages/tsx-auto-props/src/rollup.ts (1)
1-5: Consistent plugin factory pattern implementation.The refactoring to use
createRollupPluginwithunpluginFactoryfollows the same clean pattern as other build tool plugins in the package. This standardization across webpack, rollup, and other build tools improves maintainability and consistency.packages/complex-types/src/rollup.ts (1)
1-5: LGTM! Clean refactoring to factory pattern.The migration from direct
unplugin.rollupproperty access to thecreateRollupPlugin(unpluginFactory)factory pattern is well-implemented and consistent with the broader architectural changes.packages/complex-types/src/vite.ts (1)
1-5: LGTM! Consistent with the factory pattern migration.The Vite plugin integration follows the same clean factory pattern as other bundler integrations, properly importing and using
createVitePluginwith the sharedunpluginFactory.packages/tsx-auto-props/src/rspack.ts (1)
1-5: LGTM! Consistent factory pattern across packages.The Rspack plugin integration correctly implements the same factory pattern being applied across the monorepo, maintaining consistency between the
complex-typesandtsx-auto-propspackages.packages/tsx-auto-props/src/vite.ts (1)
1-5: LGTM! Factory pattern correctly implemented.The Vite plugin integration follows the established factory pattern correctly.
packages/complex-types/src/astro.ts (2)
1-4: LGTM! Correct imports for the factory pattern.The import changes properly support the new factory pattern, including the updated type import path to
"./core/types".
11-13: LGTM! Proper Astro integration with factory pattern.The Astro plugin setup correctly uses
createVitePlugin(unpluginFactory)(options)instead of the previous directunplugin.vite(options)call, which is appropriate since Astro uses Vite internally.packages/complex-types/src/esbuild.ts (1)
1-5: Migration pattern looks correct.The refactoring from direct property access to factory function invocation aligns with the Vue Language Tools v3 migration objectives and follows the standard unplugin pattern.
packages/complex-types/src/webpack.ts (1)
1-5: Consistent migration pattern applied.The webpack plugin migration follows the same factory function pattern as other build tool plugins, ensuring consistency across the codebase.
packages/language/package.json (3)
5-5: ESM migration properly implemented.The addition of
"type": "module"correctly declares this package as using ES modules, aligning with the PR objective to convert to pure ESM.
23-27: Export structure correctly simplified for ESM.The unified exports, main, and module fields pointing to the same file is appropriate for a pure ESM package, and the addition of the types field follows best practices.
35-37: Build tool migration to tsdown implemented.The switch from
unbuildtotsdownin the build scripts aligns with the broader migration strategy across the monorepo.packages/complex-types/src/rspack.ts (1)
1-5: Consistent plugin migration pattern maintained.The rspack plugin follows the same factory function pattern as other build tool plugins, ensuring uniformity across the plugin ecosystem.
packages/complex-types/src/index.ts (1)
33-35: Clean export pattern with tree-shaking support.Good use of the
/* #__PURE__ */annotation and providing both named and default exports for flexibility.packages/complex-types/src/nuxt.ts (1)
7-17: Clean Nuxt module implementation.Good use of deferred plugin creation and proper module naming. The implementation follows Nuxt best practices.
packages/tsx-auto-props/src/nuxt.ts (1)
7-17: Consistent and correct Nuxt module implementation.The module name and config key are properly set for the tsx-auto-props package. Good consistency with the complex-types implementation.
packages/complex-types/package.json (1)
5-48: Clean ES module migration.The conversion to pure ES modules is well-executed with properly structured exports and consistent paths. Good addition of support for new bundlers like Farm and Rolldown.
packages/tsx-auto-props/package.json (6)
5-5: ESM migration correctly implemented.The addition of
"type": "module"properly configures the package for ES module format, which aligns with the PR's objective to convert to pure ESM.
9-11: New build tool support added.The keywords "farm" and "rolldown" indicate support for these newer build tools, which corresponds to the new export entries and plugin files mentioned in the AI summary.
46-48: Main/module field unification is appropriate for ESM.Unifying
mainandmodulefields to point to the same ESM entry point is correct for pure ESM packages. The addition of thetypesfield properly points to the TypeScript declarations.
82-117: Comprehensive peer dependencies expansion.The significant expansion of peer dependencies and the addition of
peerDependenciesMetamarking them as optional is well-structured. This allows the package to work with multiple build tools while not requiring all of them.
64-66: tsdown migration verified successfullyVerified that
tsdown.config.tsexists inpackages/tsx-auto-props/tsdown.config.tsand there is no leftoverbuild.config.ts. The switch fromunbuildtotsdown(including the new watch script) is correctly configured and requires no further changes.
34-44: No internal CJS imports found – ensure external CJS compatibilityRan a ripgrep search across all JS/TS files for both
require('@vue.ts/tsx-auto-props')andimport … from '@vue.ts/tsx-auto-props'; no references were found. That means there are no internal consumers to break, but you should still:
- Manually test or add CI coverage for CommonJS consumers (e.g.
require('@vue.ts/tsx-auto-props')) to confirm they resolve correctly.- Consider adding back a conditional
"require"export entry or publishing a.cjsbuild if any downstream CJS users report issues.packages/language/src/index.ts (12)
4-8: Updated imports align with Vue Language Tools v3.The imports from
@volar/typescripthave been updated to include new utilities likecreateLanguageServiceHostandresolveFileLanguageId, which are consistent with the v3 migration.
13-13: External helpers module improves modularity.The import of
createHelpersfrom a separate module is a good architectural improvement that separates concerns and makes the code more maintainable.
24-24: Parameter simplification improves API.The removal of the
configFileNameparameter and direct use oftsconfigPathin thecreateParsedCommandLinecall simplifies the API without losing functionality.
36-38: File tracking improvement with Set.Converting from array to Set for
fileNamesis a good optimization that provides O(1) lookup and insertion performance while preventing duplicates.
41-47: Simplified project host interface.The
projectHostinterface has been streamlined to focus on essential TypeScript project information, which aligns with the API changes in Vue Language Tools v3.
51-56: Vue language plugin configuration updated.The plugin creation now uses the project's compilation settings and Vue options directly, which is more consistent with the v3 API structure.
58-67: Language initialization with proper configuration.The language creation now includes proper plugin configuration and file ID resolution, which provides better integration with the Vue Language Tools v3 ecosystem.
90-96: Language service host creation follows v3 pattern.The use of
createLanguageServiceHostfrom@volar/typescriptis the correct approach for v3, providing better integration with the TypeScript language service.
115-120: Helpers integration enhances functionality.The integration of external helpers provides better AST traversal and Vue-specific utilities, which improves the overall functionality of the language service.
124-145: New file management methods improve API.The addition of
updateFile,deleteFile,reload, andclearCachemethods provides a more complete API for managing the language service state, which is essential for proper integration.
154-154: Type alias improves code readability.The
Languagetype alias provides better type safety and readability throughout the codebase.
157-157: Explicit void return type for ensureLanguage.The explicit
voidreturn type forensureLanguagemakes the function's intent clearer and provides better type safety.
| import { createVitePlugin } from "unplugin"; | ||
|
|
||
| export default unplugin.vite; | ||
| import { unpluginFactory } from "."; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the plugin name in unpluginFactory.
Based on the relevant code snippet from packages/tsx-auto-props/src/index.ts, the unpluginFactory uses the name "@vue.ts/complex-types" but this is in the tsx-auto-props package. Please verify this is intentional or if it should be "@vue.ts/tsx-auto-props".
🏁 Script executed:
#!/bin/bash
# Check the plugin name in tsx-auto-props unpluginFactory
cat packages/tsx-auto-props/src/index.ts | grep -A 5 -B 5 'name.*@vue.ts'Length of output: 384
🏁 Script executed:
#!/bin/bash
# Search for other unpluginFactory plugin names across packages
rg "@vue.ts/" -n packagesLength of output: 6157
Action Required: Align plugin names in tsx-auto-props with its package name
The Vite and Astro integrations in packages/tsx-auto-props are still using "@vue.ts/complex-types" as their plugin name. They should be updated to match the package’s actual name, @vue.ts/tsx-auto-props.
• packages/tsx-auto-props/src/index.ts (≈ line 13)
• Change name: "@vue.ts/complex-types" → name: "@vue.ts/tsx-auto-props"
• packages/tsx-auto-props/src/astro.ts (≈ line 5)
• Change name: "@vue.ts/complex-types" → name: "@vue.ts/tsx-auto-props"
Note: The Nuxt integration (src/nuxt.ts) correctly uses "@vue.ts/tsx-auto-props". After applying these fixes, please scan the other entry points (Rollup, Webpack, Esbuild, etc.) in this package to ensure they all use the consistent plugin name.
🤖 Prompt for AI Agents
In packages/tsx-auto-props/src/index.ts around line 13 and
packages/tsx-auto-props/src/astro.ts around line 5, update the plugin name from
"@vue.ts/complex-types" to "@vue.ts/tsx-auto-props" to align with the package's
actual name. After making these changes, review other entry points like Rollup,
Webpack, and Esbuild in the same package to ensure they also use the consistent
plugin name "@vue.ts/tsx-auto-props".
| import { createEsbuildPlugin } from "unplugin"; | ||
|
|
||
| export default unplugin.esbuild; | ||
| import { unpluginFactory } from "."; | ||
|
|
||
| export default createEsbuildPlugin(unpluginFactory); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Migration pattern correct, but verify plugin name consistency.
The factory function pattern is correctly implemented. However, ensure that the unpluginFactory in this package uses the correct plugin name for @vue.ts/tsx-auto-props rather than @vue.ts/complex-types.
🏁 Script executed:
#!/bin/bash
# Description: Verify the plugin name in tsx-auto-props unpluginFactory matches the package name
# Expected: Plugin name should be "@vue.ts/tsx-auto-props" not "@vue.ts/complex-types"
# Check the plugin name in the unpluginFactory
rg -A 5 'name.*vue\.ts' packages/tsx-auto-props/src/index.tsLength of output: 236
Update plugin name to @vue.ts/tsx-auto-props
The unpluginFactory in packages/tsx-auto-props/src/index.ts still uses the name for the complex-types plugin. This should be updated to match the tsx-auto-props package.
• File: packages/tsx-auto-props/src/index.ts
• Location: the name property in the factory options
Suggested diff:
--- a/packages/tsx-auto-props/src/index.ts
+++ b/packages/tsx-auto-props/src/index.ts
@@ -1,5 +1,5 @@
export const unpluginFactory = (options = {}) => ({
- name: "@vue.ts/complex-types",
+ name: "@vue.ts/tsx-auto-props",
enforce: "pre",
// ...
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { createEsbuildPlugin } from "unplugin"; | |
| export default unplugin.esbuild; | |
| import { unpluginFactory } from "."; | |
| export default createEsbuildPlugin(unpluginFactory); | |
| export const unpluginFactory = (options = {}) => ({ | |
| name: "@vue.ts/tsx-auto-props", | |
| enforce: "pre", | |
| // ... | |
| }); |
🤖 Prompt for AI Agents
In packages/tsx-auto-props/src/index.ts, locate the unpluginFactory definition
and update the name property to '@vue.ts/tsx-auto-props' to correctly reflect
the tsx-auto-props package instead of the complex-types plugin name.
| }, | ||
| "devDependencies": { | ||
| "@nuxt/schema": "^3.17.6", | ||
| "rolldown": "1.0.0-beta.27", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify rolldown version compatibility.
The rolldown version 1.0.0-beta.27 is a beta release. Ensure this version is stable enough for production use and check for any known issues.
🌐 Web query:
What are the known issues and stability concerns with rolldown version 1.0.0-beta.27?
💡 Result:
Rolldown 1.0.0-beta.27 is a JavaScript/TypeScript bundler, intended as a future backbone for Vite. While direct, comprehensive documentation of its “known issues” is not present in the provided search results, there are a few important points and signs relevant to its stability and areas for concern:
-
Bug Fixes and Ongoing Issue References: Recent changes in the changelog indicate that several specific issues have been addressed or are being tracked. For example:
- Fixes for issues like handling of named export declarations, edge cases with object/array destructuring patterns, API compatibility, and the behavior of certain plugin and config options[1].
- Adjustments to
assetFileNameshash lengths, fixes forpreserve-legalcomment handling, module IDs, and others[1]. - Some items are explicitly linked to issue numbers (e.g., #4419, #4369, #4118), suggesting outstanding tickets and possibly related open problems even in the latest beta[1].
-
Active Development and Beta Status: The version is marked as a beta release which, by definition, implies:
- Potential for bugs and breaking changes: As it is not a stable release, users can expect instability, incomplete features, or regressions as development progresses.
- Frequent updates and iterations: Ongoing pull requests and dependency bumps[4] reflect rapid change, which can bring both improvements and new, unforeseen issues.
-
API and Compatibility Maturity: Rolldown aims for Rollup-compatibility, but ongoing references to plugin utilities, metadata handling, and config discovery (e.g., resolving default configs, plugin option typing) may indicate fluidity in how well it matches or replaces Rollup, which can pose migration risks for complex projects[1].
-
Lack of Consolidated Known Issues List: There is no single, definitive enumeration of “known issues” in the search results, and no statement indicating that all critical issues are resolved. Issues are referenced by commit or pull request within changelogs rather than documentation of known-blockers or critical bugs[1][4].
Stability Concerns to Note:
- Using 1.0.0-beta.27 in production environments is not recommended due to its beta status and the likely presence of unresolved bugs and breaking API changes.
- Close monitoring of its issue tracker and changelog is advised to stay informed about regressions or major changes, especially if integrating or evaluating it for critical workflows[1][4].
If absolute stability and long-term support are required, waiting for a stable release or carefully tracking the official Rolldown repository for up-to-date reported problems is essential.
Citations:
- 1: https://classic.yarnpkg.com/en/package/@rolldown/binding-darwin-x64
- 2: https://pmc.ncbi.nlm.nih.gov/articles/PMC7176285/
- 3: https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-17-1-1-4.html
- 4: https://github.com/vitejs/vite/actions/runs/16260347768
- 5: https://duplicator.com/knowledge-base/changelog/
- 6: https://www.wipo.int/documents/d/standards/docs-en-wipo-sequence-wipo-sequence-release-notes-1-0-0.pdf
- 7: https://docs.h2o.ai/driverless-ai/1-11-lts/docs/userguide/release_notes.html
- 8: https://www.contentstack.com/docs/changelog
- 9: https://docs.enthought.com/canopy/1.7/advanced.html
- 10: https://plugins.craftcms.com/rich-variables/changelog?craft5
Review βeta Dependency in package.json
The rolldown version is pinned to 1.0.0-beta.27, which is still under active development and may introduce breaking changes or unresolved bugs. Before shipping to production:
• File to update:
- packages/tsx-auto-props/package.json (line 77)
• Recommended actions:
- Consider using the latest stable Rolldown release once available, or lock to a proven Rollup-compatible bundler.
- If you must stay on βeta, add end-to-end CI tests covering your build output and watch for open issues (e.g. #4419, #4369, #4118) in the Rolldown tracker.
- Regularly monitor the changelog for breaking changes or security fixes in subsequent βeta releases.
🤖 Prompt for AI Agents
In packages/tsx-auto-props/package.json at line 77, the dependency "rolldown" is
pinned to a beta version 1.0.0-beta.27, which may be unstable for production. To
fix this, update the version to the latest stable release of Rolldown if
available, or switch to a well-tested Rollup-compatible bundler. If you must
keep the beta version, implement end-to-end CI tests for your build output and
actively monitor the Rolldown issue tracker and changelog for any breaking
changes or security fixes.
fixes #76, fixes #59
Note this PR also converts the codebase to pure ESM.
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Refactor
Chores
tsdowndocumentation and build tool support.