feat(cli): add ultracite, oxlint, fumadocs addons #427
Conversation
ok ok ok ok ok
🦋 Changeset detectedLatest commit: 71d1f89 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Caution Review failedThe pull request is closed. WalkthroughThis update expands the CLI tool's addon system by introducing three new addons ("fumadocs", "ultracite", "oxlint"), updating compatibility types and prompts, and adding setup logic for these addons. It also introduces support for the "bun" package manager, updates dependency versions, and slightly refines form event handling and type annotations throughout the codebase. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Prompts
participant Setup
participant Project
User->>CLI: Run CLI to generate project
CLI->>Prompts: Show grouped addon selection (including new addons)
Prompts->>User: User selects addons (fumadocs, ultracite, oxlint, etc.)
CLI->>Setup: For each selected addon, invoke setup logic
Setup->>Project: Configure/add files, run commands (e.g., setupFumadocs, setupUltracite, setupOxlint)
Setup->>Project: Copy bunfig.toml if bun is selected
Setup->>CLI: Return setup results
CLI->>User: Output post-install instructions (including Fumadocs message if selected)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes detected related to the linked issue objectives. Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests
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 (
|
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
apps/cli/src/helpers/setup/fumadocs-setup.ts (1)
62-73: Consider making hardcoded command flags configurableThe command construction uses several hardcoded flags (
--src --no-install --pm bun --no-eslint). While these may be appropriate defaults, consider whether some of these should be configurable, particularly the package manager flag which currently forcesbunregardless of the project's configured package manager.- const commandWithArgs = `create-fumadocs-app@latest fumadocs --template ${templateArg} --src --no-install --pm bun --no-eslint`; + const commandWithArgs = `create-fumadocs-app@latest fumadocs --template ${templateArg} --src --no-install --pm ${packageManager} --no-eslint`;apps/cli/src/prompts/addons.ts (1)
119-120: Remove commented code or add explanation.Consider removing the commented configuration options or adding a comment explaining why they're preserved (e.g., for future use or testing).
- // groupSpacing: 1, - selectableGroups: false, + selectableGroups: false,Also applies to: 176-177
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (22)
apps/cli/src/constants.ts(3 hunks)apps/cli/src/helpers/project-generation/post-installation.ts(1 hunks)apps/cli/src/helpers/project-generation/template-manager.ts(1 hunks)apps/cli/src/helpers/setup/addons-setup.ts(6 hunks)apps/cli/src/helpers/setup/fumadocs-setup.ts(1 hunks)apps/cli/src/helpers/setup/ultracite-setup.ts(1 hunks)apps/cli/src/prompts/addons.ts(2 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/sponsors.ts(1 hunks)apps/cli/src/validation.ts(1 hunks)apps/cli/templates/addons/biome/biome.json.hbs(1 hunks)apps/cli/templates/auth/web/react/next/src/components/sign-in-form.tsx(1 hunks)apps/cli/templates/auth/web/react/next/src/components/sign-up-form.tsx(1 hunks)apps/cli/templates/auth/web/react/react-router/src/components/sign-in-form.tsx(1 hunks)apps/cli/templates/auth/web/react/react-router/src/components/sign-up-form.tsx(1 hunks)apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-in-form.tsx(1 hunks)apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-up-form.tsx(1 hunks)apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-in-form.tsx(1 hunks)apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-up-form.tsx(1 hunks)apps/cli/templates/auth/web/solid/src/components/sign-in-form.tsx(1 hunks)apps/cli/templates/auth/web/solid/src/components/sign-up-form.tsx(1 hunks)apps/cli/templates/extras/bunfig.toml(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-up-form.tsx (2)
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Query documentation uses $any() in Angular templates when handling events, particularly with form handling and the @tanstack/angular-form library. The $any() approach is officially recommended by TanStack for their Angular implementations rather than using explicit type assertions like ($event.target as HTMLInputElement).
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Form's official documentation uses $any($event).target.value pattern in input event handlers within Angular templates. This is the recommended approach by TanStack, as shown in their examples: (input)="field.api.handleChange($any($event).target.value)". Using explicit type assertions like ($event.target as HTMLInputElement).value does not work with TanStack Form's Angular integration.
apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-in-form.tsx (2)
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Query documentation uses $any() in Angular templates when handling events, particularly with form handling and the @tanstack/angular-form library. The $any() approach is officially recommended by TanStack for their Angular implementations rather than using explicit type assertions like ($event.target as HTMLInputElement).
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Form's official documentation uses $any($event).target.value pattern in input event handlers within Angular templates. This is the recommended approach by TanStack, as shown in their examples: (input)="field.api.handleChange($any($event).target.value)". Using explicit type assertions like ($event.target as HTMLInputElement).value does not work with TanStack Form's Angular integration.
apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-up-form.tsx (2)
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Form's official documentation uses $any($event).target.value pattern in input event handlers within Angular templates. This is the recommended approach by TanStack, as shown in their examples: (input)="field.api.handleChange($any($event).target.value)". Using explicit type assertions like ($event.target as HTMLInputElement).value does not work with TanStack Form's Angular integration.
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Query documentation uses $any() in Angular templates when handling events, particularly with form handling and the @tanstack/angular-form library. The $any() approach is officially recommended by TanStack for their Angular implementations rather than using explicit type assertions like ($event.target as HTMLInputElement).
apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-in-form.tsx (2)
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Form's official documentation uses $any($event).target.value pattern in input event handlers within Angular templates. This is the recommended approach by TanStack, as shown in their examples: (input)="field.api.handleChange($any($event).target.value)". Using explicit type assertions like ($event.target as HTMLInputElement).value does not work with TanStack Form's Angular integration.
Learnt from: Vijayabaskar56
PR: #310
File: apps/cli/templates/examples/todo/web/angular/src/components/todo-list/todo-list.component.html:0-0
Timestamp: 2025-06-08T18:34:46.364Z
Learning: TanStack Angular Query documentation uses $any() in Angular templates when handling events, particularly with form handling and the @tanstack/angular-form library. The $any() approach is officially recommended by TanStack for their Angular implementations rather than using explicit type assertions like ($event.target as HTMLInputElement).
🧬 Code Graph Analysis (4)
apps/cli/src/helpers/project-generation/post-installation.ts (1)
apps/cli/src/helpers/project-generation/add-addons.ts (1)
addAddonsToProject(20-103)
apps/cli/src/helpers/project-generation/template-manager.ts (1)
apps/cli/src/helpers/setup/runtime-setup.ts (1)
setupBunRuntime(68-89)
apps/cli/src/types.ts (1)
apps/cli/src/utils/addon-compatibility.ts (1)
validateAddonCompatibility(4-27)
apps/cli/src/prompts/addons.ts (1)
apps/cli/src/helpers/project-generation/command-handlers.ts (1)
addAddonsHandler(139-221)
🔇 Additional comments (38)
apps/cli/templates/extras/bunfig.toml (1)
1-2: Good choice for the linker configuration.The
isolatedlinker setting is appropriate for a CLI scaffolding tool, as it prevents dependency conflicts between generated projects by creating isolatednode_modulesdirectories.apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-in-form.tsx (1)
65-65: Consistent removal of void operator aligns with modern practices.Removing the
voidoperator fromform.handleSubmit()is appropriate since error handling is already managed through theonErrorcallback in the form configuration. This change standardizes the form submission pattern across components.apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-in-form.tsx (1)
65-65: Consistent change across React templates.The removal of the
voidoperator maintains consistency with other form components in the codebase while preserving proper error handling through the form'sonErrorcallback.apps/cli/templates/auth/web/react/react-router/src/components/sign-up-form.tsx (1)
64-64: Maintains consistency across authentication forms.The removal of the
voidoperator follows the same pattern applied across sign-in and sign-up forms, creating a unified approach to form submission handling while maintaining proper error management.apps/cli/templates/auth/web/react/next/src/components/sign-up-form.tsx (1)
64-64: Completes the standardization across all React frameworks.This change finalizes the consistent removal of
voidoperators across Next.js, React Router, and TanStack Router templates, creating a unified form submission pattern while preserving error handling through configured callbacks.apps/cli/templates/auth/web/react/tanstack-router/src/components/sign-up-form.tsx (1)
68-68: Approved: Promise handling change in form submissionThe removal of the
voidoperator allows the Promise returned byform.handleSubmit()to be naturally handled rather than explicitly discarded. This change is consistent with similar updates across all auth form components and doesn't affect the actual submission logic.apps/cli/templates/auth/web/react/tanstack-start/src/components/sign-up-form.tsx (1)
68-68: Approved: Consistent Promise handling standardizationSame beneficial change as other auth form components - removing explicit Promise discarding in favor of natural Promise handling.
apps/cli/templates/auth/web/react/react-router/src/components/sign-in-form.tsx (1)
61-61: Approved: Promise handling consistency maintainedThe change aligns with the standardization effort across all authentication forms, removing explicit Promise discarding.
apps/cli/templates/auth/web/solid/src/components/sign-in-form.tsx (1)
56-56: Approved: Cross-framework Promise handling standardizationThe change extends the Promise handling standardization to Solid.js templates, maintaining consistency across React and Solid authentication forms.
apps/cli/templates/auth/web/solid/src/components/sign-up-form.tsx (1)
59-59: Approved: Completes Promise handling standardizationThis final change completes the consistent Promise handling standardization across all authentication form templates in both React and Solid frameworks.
apps/cli/templates/addons/biome/biome.json.hbs (1)
2-2: Schema version 2.1.2 is valid and compatible.Version 2.1.2 is a stable release that updates the
$schemaURL and refines linter and import-organizer behaviors without introducing new breaking changes beyond those in v2.0.0. Your existing configuration remains compatible—no further action required.apps/cli/templates/auth/web/react/next/src/components/sign-in-form.tsx (1)
61-61: Verify the impact of removing the void operator.The
voidoperator was removed fromform.handleSubmit(). If this method returns a promise, removingvoidcould lead to unhandled promise warnings or unexpected behavior. Please confirm that this change is intentional and that any returned promises are properly handled.apps/cli/src/helpers/project-generation/post-installation.ts (1)
145-147: LGTM! Clean addition following established patterns.The fumadocs addon instruction follows the same pattern as the existing starlight addon, with appropriate conditional checking and consistent formatting. The port 4000 choice is reasonable and distinct from other services.
apps/cli/src/validation.ts (1)
503-503: LGTM! Good code style improvement.Removing the explicit
voidreturn type and formatting the parameters on a single line improves consistency without affecting functionality.apps/cli/src/helpers/project-generation/template-manager.ts (1)
793-799: LGTM! Consistent implementation following established patterns.The bun package manager support follows the exact same pattern as the existing pnpm logic, with proper file existence checks and consistent error handling. This integrates well with the existing bun support shown in the relevant code snippets.
apps/cli/src/types.ts (1)
42-53: LGTM: New addon types properly integratedThe addition of
"fumadocs","ultracite", and"oxlint"to theAddonsSchemaenum follows the existing pattern and maintains type safety. The changes align well with the corresponding updates in the constants file where these addons are added to theADDON_COMPATIBILITYmapping.apps/cli/src/utils/sponsors.ts (1)
37-37: LGTM: Minor stylistic improvementRemoving the explicit
: voidreturn type annotation is appropriate here since TypeScript can infer the void return type automatically. This aligns with modern TypeScript practices.apps/cli/src/helpers/setup/fumadocs-setup.ts (4)
16-37: LGTM: Well-structured template configurationThe
TEMPLATESconstant provides a clean mapping between template keys and their CLI values, with appropriate labels and hints for user selection. The structure is maintainable and follows good practices.
45-58: LGTM: Proper user input handling with cancellation supportThe template selection logic correctly handles user cancellation and provides appropriate feedback. The initial value selection of "next-mdx" as recommended is a good UX choice.
78-87: LGTM: Thoughtful package.json modificationsThe logic to update the package name and append the port argument to the dev script is well-implemented. The conditional check for the dev script existence prevents errors, and using a specific port (4000) helps avoid conflicts with the main application.
90-96: LGTM: Comprehensive error handlingThe error handling properly catches exceptions, provides user-friendly messages, and includes detailed error information when available. The logging approach is consistent with the rest of the codebase.
apps/cli/src/helpers/setup/ultracite-setup.ts (5)
17-53: LGTM: Comprehensive editor and rule configurationsThe
EDITORSandRULESconstants provide clear mappings with descriptive labels and helpful hints. The categorization covers major editors and AI tools, giving users good options for their development setup.
55-61: LGTM: Good integration with Biome setupCalling
setupBiomefirst makes sense as Ultracite likely depends on Biome for linting functionality. The function signature appropriately accepts thehasHuskyparameter for conditional feature integration.
63-91: LGTM: Well-structured user input handlingThe multiselect prompts for editors and rules provide good UX with proper labeling and cancellation handling. Setting
required: falseallows users to skip selections if desired, which is appropriate for optional configurations.
93-119: LGTM: Dynamic command construction with proper feature integrationThe command argument building is well-structured, dynamically adding editors and rules based on user selections. The conditional inclusion of Husky and lint-staged features when
hasHuskyis true shows good integration with the broader project setup.
122-128: LGTM: Consistent error handling patternThe error handling follows the same pattern as other setup functions, providing user-friendly messages and detailed error information. Using
console.errorinstead ofconsola.erroris consistent with the simpler error reporting approach.apps/cli/src/constants.ts (2)
3-3: LGTM: Import addition supports explicit typingAdding
Addonsto the imports is necessary to support the explicit type annotation forADDON_COMPATIBILITY, improving type safety.
123-134: LGTM: Explicit typing improves type safetyAdding the explicit
Record<Addons, readonly Frontend[]>type annotation ensures compile-time verification that all addon types are accounted for in the compatibility mapping. The empty arrays for the new addons (ultracite,oxlint,fumadocs) indicate they're compatible with all frontend frameworks, which seems appropriate for these development tools.apps/cli/src/helpers/setup/addons-setup.ts (5)
3-12: LGTM - Imports are properly organized.The new imports support the expanded addon functionality and are correctly structured.
16-16: Good refactoring for improved readability.Extracting the packageManager and creating boolean flags makes the conditional logic more maintainable.
Also applies to: 60-64
65-81: Well-structured conditional logic for addon prioritization.The logic correctly prioritizes ultracite and properly determines the appropriate linter for lint-staged configuration when falling back to individual setups.
83-91: Consistent integration of new addon setups.The new addon setups follow the established patterns and pass the appropriate parameters.
107-107: Good architectural decision to export setupBiome.Exporting the function enables reuse by other setup modules, improving modularity.
apps/cli/src/prompts/addons.ts (5)
1-1: Correct import change for grouped addon selection.The change from
multiselecttogroupMultiselectaligns with the new categorized addon selection interface.
20-60: Excellent refactoring to switch statement with accurate addon descriptions.The switch statement improves maintainability over the if-else chain, and the new addon descriptions are clear and accurate.
65-69: Logical addon categorization improves user experience.The grouping of addons into Documentation, Linting, and Other categories makes the selection interface more intuitive and organized.
78-121: Well-implemented grouped addon selection.The refactoring properly categorizes addons and handles empty groups gracefully. The grouped interface will provide a better user experience.
135-170: Consistent implementation with proper edge case handling.The getAddonsToAdd function correctly implements the same grouped selection pattern and properly handles the case when no compatible addons are available.
apps/cli/src/constants.ts
Outdated
| "@biomejs/biome": "^2.1.2", | ||
| oxlint: "^1.8.0", | ||
|
|
||
| husky: "^9.1.7", | ||
| "lint-staged": "^15.5.0", | ||
| "lint-staged": "^16.1.2", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify dependency version updates are current and secure
The version updates for @biomejs/biome (^2.0.0 → ^2.1.2), lint-staged (^15.5.0 → ^16.1.2), and the new oxlint (^1.8.0) should be verified to ensure they represent the latest stable versions and don't introduce security vulnerabilities.
🌐 Web query:
What are the latest stable versions of @biomejs/biome, lint-staged, and oxlint packages, and are there any known security issues with these versions?
💡 Result:
The latest stable versions for the requested packages as of July 27, 2025, and their known security status, are as follows:
@biomejs/biome
- The latest stable version is v2.0, officially released in June 2025[9].
- This release is notable for introducing type-aware linting without relying on the TypeScript compiler[9].
- There are no currently known or reported security issues affecting this latest version as of the available sources[3][9]. Security sources classify the project as having a “healthy version release cadence and project activity”[3].
lint-staged
- The latest stable version is v16.1.0, released on May 27, 2025[2].
- This update includes new command-line flags and minor improvements[2].
- There are no security advisories or reported vulnerabilities affecting v16.1.0 according to security analysis tools and the project’s changelog[2][6].
oxlint
- There is no recent release information or security advisory for oxlint within the provided search results.
- If you require the precise latest version and security information for oxlint, please consult the npm registry or the official Oxlint repository directly, as up-to-date release and advisory details were not returned by the provided search results.
Summary Table
| Package | Latest Stable Version | Release Date | Known Security Issues |
|---|---|---|---|
| @biomejs/biome | v2.0 | 2025-06-17 | None reported[3][9] |
| lint-staged | v16.1.0 | 2025-05-27 | None reported[2][6] |
| oxlint | Not specified | Not specified | Not available in search results |
Caveats & Limitations
- Security status is based on current public information. For mission-critical applications, always verify against centralized advisories such as npm, Socket.dev, GitHub Security Advisories, or CVE databases.
- Precise version and security details for oxlint were not found in the returned sources; external verification is recommended for the most accurate and up-to-date info.
Citations:
- 1: https://biomejs.dev/blog/biome-v2-0-beta/
- 2: https://github.com/lint-staged/lint-staged/releases
- 3: https://socket.dev/npm/package/@biomejs/biome
- 4: https://biomejs.dev/internals/changelog_v1/
- 5: https://biomejs.dev/blog/roadmap-2025/
- 6: https://classic.yarnpkg.com/en/package/lint-staged
- 7: https://biomejs.dev/blog/biome-v1-5/
- 8: https://biomejs.dev/linter/
- 9: https://biomejs.dev/blog/biome-v2/
- 10: https://github.com/lint-staged/lint-staged
Action Required: Validate and Correct Dependency Versions
It looks like the versions specified in apps/cli/src/constants.ts (lines 58–62) don’t align with what’s currently published on npm:
• @biomejs/biome: "^2.1.2" – npm’s latest stable is 2.0.0 (Jun 2025). Please confirm ^2.1.2 actually exists or roll back to "^2.0.0".
• lint-staged: "^16.1.2" – npm’s latest stable is 16.1.0. Update to "^16.1.0" or verify the 16.1.2 release.
• oxlint: "^1.8.0" – no release information found. Verify that v1.8.0 is published and free of advisories.
• If you intended to pin pre-releases or unpublished packages, ensure your registry configuration supports them.
• Otherwise, update these entries to the latest valid versions and rerun your vulnerability scans.
🤖 Prompt for AI Agents
In apps/cli/src/constants.ts between lines 58 and 62, verify the versions of
@biomejs/biome, lint-staged, and oxlint against the official npm registry. If
the specified versions (^2.1.2 for @biomejs/biome, ^16.1.2 for lint-staged, and
^1.8.0 for oxlint) do not exist or are unpublished, update them to the latest
stable versions available (^2.0.0 for @biomejs/biome, ^16.1.0 for lint-staged)
or confirm the existence and validity of oxlint v1.8.0. Adjust the version
strings accordingly and ensure your registry configuration supports any
pre-release or unpublished packages if those are intentional.
| } else { | ||
| packageJson["lint-staged"] = { | ||
| "**/*.{js,mjs,cjs,jsx,ts,mts,cts,tsx,vue,astro,svelte}": "", | ||
| }; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider handling the no-linter case more gracefully.
Setting an empty command for lint-staged when no linter is specified may cause issues. Consider either omitting the lint-staged configuration entirely or providing a meaningful default command.
- } else {
- packageJson["lint-staged"] = {
- "**/*.{js,mjs,cjs,jsx,ts,mts,cts,tsx,vue,astro,svelte}": "",
- };
- }
+ }
+ // Note: If no linter is specified, we don't configure lint-staged📝 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.
| } else { | |
| packageJson["lint-staged"] = { | |
| "**/*.{js,mjs,cjs,jsx,ts,mts,cts,tsx,vue,astro,svelte}": "", | |
| }; | |
| } | |
| } | |
| // Note: If no linter is specified, we don't configure lint-staged |
🤖 Prompt for AI Agents
In apps/cli/src/helpers/setup/addons-setup.ts around lines 154 to 158, the
current code sets an empty string as the lint-staged command when no linter is
specified, which can cause issues. Instead, modify the logic to either omit the
lint-staged property from packageJson entirely in this case or assign a
meaningful default command that safely handles staged files without errors.
| packageJson.scripts = { | ||
| ...packageJson.scripts, | ||
| check: "oxlint", | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Potential script name conflict with other linters.
The hardcoded "check" script name may conflict with biome's check script if both addons are installed. Consider using a more specific name like "oxlint-check" or implementing logic to handle script name conflicts.
- packageJson.scripts = {
- ...packageJson.scripts,
- check: "oxlint",
- };
+ packageJson.scripts = {
+ ...packageJson.scripts,
+ "oxlint-check": "oxlint",
+ };📝 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.
| packageJson.scripts = { | |
| ...packageJson.scripts, | |
| check: "oxlint", | |
| }; | |
| packageJson.scripts = { | |
| ...packageJson.scripts, | |
| "oxlint-check": "oxlint", | |
| }; |
🤖 Prompt for AI Agents
In apps/cli/src/helpers/setup/addons-setup.ts around lines 211 to 214, the
script name "check" is hardcoded and may conflict with other linters like biome.
To fix this, rename the script to a more specific name such as "oxlint-check" to
avoid conflicts. Alternatively, implement logic to detect existing script names
and adjust accordingly to prevent overwriting or conflicts.
| await execa(oxlintInitCommand, { | ||
| cwd: projectDir, | ||
| env: { CI: "true" }, | ||
| shell: true, | ||
| }); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling for the oxlint initialization command.
The execa command should include error handling to provide meaningful feedback if the initialization fails.
- await execa(oxlintInitCommand, {
- cwd: projectDir,
- env: { CI: "true" },
- shell: true,
- });
+ try {
+ await execa(oxlintInitCommand, {
+ cwd: projectDir,
+ env: { CI: "true" },
+ shell: true,
+ });
+ } catch (error) {
+ console.warn("Failed to initialize oxlint configuration:", error);
+ // Continue execution as this is not critical for the setup
+ }📝 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.
| await execa(oxlintInitCommand, { | |
| cwd: projectDir, | |
| env: { CI: "true" }, | |
| shell: true, | |
| }); | |
| } | |
| try { | |
| await execa(oxlintInitCommand, { | |
| cwd: projectDir, | |
| env: { CI: "true" }, | |
| shell: true, | |
| }); | |
| } catch (error) { | |
| console.warn("Failed to initialize oxlint configuration:", error); | |
| // Continue execution as this is not critical for the setup | |
| } | |
| } |
🤖 Prompt for AI Agents
In apps/cli/src/helpers/setup/addons-setup.ts around lines 224 to 229, the execa
call running the oxlint initialization command lacks error handling. Wrap the
execa call in a try-catch block to catch any errors thrown during execution, and
in the catch block, log or throw a meaningful error message that includes
details about the failure to help with debugging.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
apps/web/src/app/llms-full.txt/route.ts (1)
6-11: Consider memory usage for large documentation sets.Loading and processing all pages concurrently could consume significant memory for large documentation sites. Consider if pagination or streaming would be more appropriate for production use.
apps/web/src/lib/get-llm-text.ts (1)
20-25: Validate page data structure to prevent runtime errors.The function assumes specific properties exist on
page.datawithout validation. Consider adding null checks or validation to prevent runtime errors if the page structure is unexpected.return `# ${page.data.title} URL: ${page.url} -${page.data.description} +${page.data.description || ''} ${processed.value}`;apps/web/src/app/(home)/_components/stack-builder.tsx (1)
1000-1019: Verify the hardcoded addon validation list.The
validAddonsarray contains a hardcoded list of supported addons. This creates a maintenance burden and potential for inconsistency.Consider deriving this list dynamically from the
TECH_OPTIONS.addonsto reduce duplication:-const validAddons = stackState.addons.filter((addon) => - [ - "pwa", - "tauri", - "starlight", - "biome", - "husky", - "turborepo", - "ultracite", - "fumadocs", - "oxlint", - ].includes(addon), -); +const validAddons = stackState.addons.filter((addon) => + TECH_OPTIONS.addons.some(option => option.id === addon) +);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
apps/web/public/icon/ultracite.svgis excluded by!**/*.svg
📒 Files selected for processing (40)
apps/cli/src/constants.ts(3 hunks)apps/cli/src/helpers/database-providers/d1-setup.ts(1 hunks)apps/cli/src/helpers/database-providers/docker-compose-setup.ts(1 hunks)apps/cli/src/helpers/database-providers/neon-setup.ts(1 hunks)apps/cli/src/helpers/database-providers/turso-setup.ts(1 hunks)apps/cli/src/helpers/project-generation/add-addons.ts(1 hunks)apps/cli/src/helpers/project-generation/add-deployment.ts(1 hunks)apps/cli/src/helpers/project-generation/command-handlers.ts(1 hunks)apps/cli/src/helpers/project-generation/env-setup.ts(2 hunks)apps/cli/src/helpers/project-generation/git.ts(1 hunks)apps/cli/src/helpers/project-generation/project-config.ts(4 hunks)apps/cli/src/helpers/project-generation/template-manager.ts(11 hunks)apps/cli/src/helpers/setup/api-setup.ts(1 hunks)apps/cli/src/helpers/setup/auth-setup.ts(1 hunks)apps/cli/src/helpers/setup/backend-setup.ts(1 hunks)apps/cli/src/helpers/setup/db-setup.ts(1 hunks)apps/cli/src/helpers/setup/examples-setup.ts(1 hunks)apps/cli/src/helpers/setup/runtime-setup.ts(5 hunks)apps/cli/src/helpers/setup/starlight-setup.ts(1 hunks)apps/cli/src/helpers/setup/tauri-setup.ts(1 hunks)apps/cli/src/helpers/setup/ultracite-setup.ts(1 hunks)apps/cli/src/helpers/setup/vite-pwa-setup.ts(1 hunks)apps/cli/src/helpers/setup/web-deploy-setup.ts(3 hunks)apps/cli/src/helpers/setup/workers-nuxt-setup.ts(1 hunks)apps/cli/src/helpers/setup/workers-svelte-setup.ts(1 hunks)apps/cli/src/helpers/setup/workers-tanstack-start-setup.ts(1 hunks)apps/cli/src/helpers/setup/workers-vite-setup.ts(1 hunks)apps/cli/src/utils/add-package-deps.ts(1 hunks)apps/cli/src/utils/analytics.ts(1 hunks)apps/cli/src/utils/bts-config.ts(2 hunks)apps/cli/src/utils/open-url.ts(1 hunks)apps/cli/src/utils/template-processor.ts(1 hunks)apps/web/next.config.mjs(1 hunks)apps/web/scripts/generate-analytics.ts(1 hunks)apps/web/src/app/(home)/_components/stack-builder.tsx(5 hunks)apps/web/src/app/llms-full.txt/route.ts(1 hunks)apps/web/src/app/llms.mdx/[[...slug]]/route.ts(1 hunks)apps/web/src/lib/constant.ts(5 hunks)apps/web/src/lib/get-llm-text.ts(1 hunks)apps/web/src/lib/types.ts(1 hunks)
✅ Files skipped from review due to trivial changes (21)
- apps/cli/src/helpers/setup/examples-setup.ts
- apps/cli/src/helpers/setup/workers-tanstack-start-setup.ts
- apps/cli/src/utils/open-url.ts
- apps/cli/src/helpers/setup/tauri-setup.ts
- apps/cli/src/helpers/project-generation/add-addons.ts
- apps/cli/src/helpers/setup/workers-svelte-setup.ts
- apps/cli/src/utils/analytics.ts
- apps/cli/src/helpers/setup/db-setup.ts
- apps/web/scripts/generate-analytics.ts
- apps/cli/src/utils/add-package-deps.ts
- apps/cli/src/helpers/setup/auth-setup.ts
- apps/cli/src/helpers/database-providers/d1-setup.ts
- apps/cli/src/helpers/database-providers/turso-setup.ts
- apps/cli/src/helpers/setup/workers-nuxt-setup.ts
- apps/cli/src/helpers/project-generation/command-handlers.ts
- apps/cli/src/helpers/database-providers/docker-compose-setup.ts
- apps/cli/src/helpers/setup/vite-pwa-setup.ts
- apps/cli/src/helpers/setup/starlight-setup.ts
- apps/cli/src/helpers/setup/workers-vite-setup.ts
- apps/cli/src/utils/bts-config.ts
- apps/cli/src/helpers/setup/api-setup.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- apps/cli/src/constants.ts
- apps/cli/src/helpers/setup/ultracite-setup.ts
- apps/cli/src/helpers/project-generation/template-manager.ts
🧰 Additional context used
🧬 Code Graph Analysis (11)
apps/cli/src/helpers/project-generation/add-deployment.ts (1)
apps/cli/src/prompts/web-deploy.ts (2)
getDeploymentToAdd(66-113)getDeploymentDisplay(16-30)
apps/web/src/app/llms-full.txt/route.ts (3)
apps/web/src/app/llms.mdx/[[...slug]]/route.ts (2)
revalidate(6-6)GET(8-17)apps/web/src/lib/source.ts (1)
source(4-7)apps/web/src/lib/get-llm-text.ts (1)
getLLMText(14-26)
apps/cli/src/helpers/setup/backend-setup.ts (1)
apps/cli/src/types.ts (1)
ProjectConfig(143-161)
apps/cli/src/utils/template-processor.ts (1)
apps/cli/src/utils/project-directory.ts (1)
handleDirectoryConflict(8-80)
apps/cli/src/helpers/database-providers/neon-setup.ts (1)
apps/cli/src/types.ts (1)
ProjectConfig(143-161)
apps/cli/src/helpers/setup/runtime-setup.ts (1)
apps/cli/src/types.ts (2)
ProjectConfig(143-161)Backend(16-16)
apps/cli/src/helpers/setup/web-deploy-setup.ts (1)
apps/cli/src/types.ts (1)
ProjectConfig(143-161)
apps/cli/src/helpers/project-generation/env-setup.ts (1)
apps/cli/src/types.ts (1)
ProjectConfig(143-161)
apps/cli/src/helpers/project-generation/project-config.ts (1)
apps/cli/src/helpers/setup/addons-setup.ts (1)
setupHusky(99-122)
apps/web/src/app/(home)/_components/stack-builder.tsx (2)
apps/web/src/lib/constant.ts (1)
DEFAULT_STACK(665-682)apps/web/src/app/(home)/_components/FeatureCard.tsx (2)
TechIcon(23-71)FeatureCard(73-125)
apps/web/src/lib/constant.ts (1)
apps/web/src/lib/types.ts (1)
TechCategory(1-16)
🔇 Additional comments (26)
apps/cli/src/helpers/database-providers/neon-setup.ts (1)
158-158: LGTM! Clean removal of redundant return type annotation.Removing the explicit
Promise<void>return type annotation simplifies the function signature while maintaining the same behavior, as TypeScript will automatically infer this return type for async functions that don't explicitly return a value.apps/cli/src/helpers/project-generation/git.ts (1)
5-5: LGTM! Clean type annotation removal.The removal of the explicit
: Promise<void>return type annotation is appropriate since TypeScript can infer the return type from theasyncfunction declaration. This change aligns with the broader codebase cleanup pattern mentioned in the PR summary.apps/cli/src/utils/template-processor.ts (1)
17-17: LGTM! Good simplification of type annotation.Removing the explicit
: Promise<void>return type is appropriate here since TypeScript can automatically infer the return type from the async function that doesn't explicitly return a value. This aligns with modern TypeScript practices and the broader codebase cleanup mentioned in the PR.apps/cli/src/helpers/setup/web-deploy-setup.ts (3)
10-10: LGTM: Simplified function signature by leveraging TypeScript inference.Removing the explicit
Promise<void>return type annotation is appropriate since TypeScript can infer this for async functions that don't return a value. This aligns with the broader codebase pattern mentioned in the PR.
42-42: LGTM: Consistent with TypeScript inference pattern.The removal of the explicit
Promise<void>return type is consistent with the pattern applied to other async functions in this file and across the CLI helper modules.
68-68: LGTM: Proper use of TypeScript type inference.The simplified function signature maintains type safety while reducing verbosity, consistent with modern TypeScript practices and the overall refactoring approach in this PR.
apps/cli/src/helpers/project-generation/env-setup.ts (2)
12-15: LGTM! Type annotation removal improves consistency.Removing the explicit
Promise<void>return type annotation is appropriate here since TypeScript can infer the return type for async functions that don't explicitly return values.
87-87: LGTM! Consistent with the broader type annotation cleanup.The removal of the explicit
Promise<void>return type annotation aligns with the consistent pattern throughout this PR and improves code readability by relying on TypeScript's type inference.apps/cli/src/helpers/project-generation/add-deployment.ts (1)
19-21: LGTM! Consistent type annotation cleanup.The removal of the explicit
Promise<void>return type annotation is consistent with the broader pattern in this PR and appropriate for async functions that don't explicitly return values.apps/cli/src/helpers/project-generation/project-config.ts (4)
7-10: LGTM! Type annotation removal improves consistency.The removal of the explicit
Promise<void>return type annotation is appropriate and consistent with the broader pattern in this PR.
19-22: LGTM! Consistent type annotation cleanup and improved separation of concerns.The removal of the explicit
Promise<void>return type annotation aligns with the PR's consistency improvements. The refactoring of addon-specific setup logic (like biome and husky) to dedicated modules inaddons-setup.tsimproves separation of concerns and maintainability.
223-226: LGTM! Type annotation removal is consistent.The removal of the explicit
Promise<void>return type annotation follows the established pattern in this PR.
275-278: LGTM! Consistent with the type annotation cleanup pattern.The removal of the explicit
Promise<void>return type annotation is appropriate and maintains consistency with other functions in this PR.apps/cli/src/helpers/setup/backend-setup.ts (1)
6-6: LGTM: Clean removal of redundant return type annotation.The removal of the explicit
Promise<void>return type annotation is appropriate since TypeScript can infer this automatically. This change aligns with the broader refactoring pattern across the codebase for consistency.apps/cli/src/helpers/setup/runtime-setup.ts (1)
9-9: LGTM: Consistent removal of redundant return type annotations.The removal of explicit
Promise<void>return type annotations from all async functions is consistent with the broader refactoring pattern. TypeScript can automatically infer these return types, making the code cleaner without affecting functionality.Also applies to: 31-31, 66-66, 86-86, 118-118
apps/web/next.config.mjs (1)
33-36: LGTM: Rewrite rule correctly supports new MDX documentation feature.The new rewrite rule properly maps documentation URLs with
.mdxextensions to the new LLM text extraction route handler. The pattern syntax is correct and aligns with the newly introduced MDX processing functionality.apps/web/src/lib/types.ts (1)
1-16: LGTM! Well-structured type refactoring.The revision of
TechCategoryto include more granular categories like"addons","webFrontend","packageManager"etc. aligns well with the PR objective of adding new addons support. The removal of theTechNodeinterface appears to be part of a broader simplification effort.apps/web/src/app/llms.mdx/[[...slug]]/route.ts (1)
1-22: Verify relevance to PR objectives.This new LLM route handler appears unrelated to the stated PR objective of adding "ultracite, oxlint, fumadocs addons". While the implementation looks correct, please confirm this file should be included in this PR or if it belongs to a separate feature.
The route implementation itself looks good - proper error handling with
notFound(), async parameter handling, and static generation support.Likely an incorrect or invalid review comment.
apps/web/src/app/(home)/_components/stack-builder.tsx (3)
132-175: LGTM! Good refactoring to named function declaration.The conversion from anonymous function expression to named function declaration improves code readability and debugging while maintaining the same functionality.
759-792: Excellent addon compatibility logic.The new compatibility checks show good attention to preventing linter conflicts:
- Warning when husky is selected without a linter
- Automatic removal of biome when ultracite is selected (since ultracite includes biome)
- Advisory note when both oxlint and biome are selected
This ensures a smooth user experience and prevents configuration conflicts.
1739-1742: Good className merge implementation.The use of
cn()utility to merge the tech-specificclassNamewith base styling provides flexibility for per-addon styling while maintaining consistency.apps/web/src/lib/constant.ts (5)
1-14: Excellent type safety improvement.The explicit
Record<TechCategory, ...>type annotation provides much better type safety and IntelliSense support compared to an implicit object type. This ensures all required categories are present and properly typed.
113-114: Good styling consistency for theme-aware icons.Adding
className: "invert-0 dark:invert"to native frontend options ensures proper icon visibility across light and dark themes.Also applies to: 122-123
386-387: Consistent theme-aware styling for npm icon.The addition of the invert className for npm maintains consistency with other icons that need theme-aware styling.
445-469: Well-defined new addon entries.All three new addons (ultracite, fumadocs, oxlint) are properly defined with:
- Appropriate descriptions that clearly explain their purpose
- Consistent color schemes using Tailwind gradient classes
- Proper default flags (false for all, which is appropriate for addons)
- Ultracite includes theme-aware className for its icon
The descriptions are clear and help users understand each addon's purpose.
445-453: Ultracite icon file verifiedThe file
apps/web/public/icon/ultracite.svgexists and matches the referenced path/icon/ultracite.svg. No changes needed.
| export async function GET() { | ||
| const scan = source.getPages().map(getLLMText); | ||
| const scanned = await Promise.all(scan); | ||
|
|
||
| return new Response(scanned.join("\n\n")); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding error handling for robustness.
The current implementation doesn't handle potential failures in getLLMText. If any page processing fails, the entire request will fail. Consider adding error handling to gracefully handle individual page processing failures.
export async function GET() {
- const scan = source.getPages().map(getLLMText);
- const scanned = await Promise.all(scan);
+ const pages = source.getPages();
+ const results = await Promise.allSettled(pages.map(getLLMText));
+ const scanned = results
+ .filter((result): result is PromiseFulfilledResult<string> => result.status === 'fulfilled')
+ .map(result => result.value);
return new Response(scanned.join("\n\n"));
}📝 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.
| export async function GET() { | |
| const scan = source.getPages().map(getLLMText); | |
| const scanned = await Promise.all(scan); | |
| return new Response(scanned.join("\n\n")); | |
| } | |
| export async function GET() { | |
| const pages = source.getPages(); | |
| const results = await Promise.allSettled(pages.map(getLLMText)); | |
| const scanned = results | |
| .filter((result): result is PromiseFulfilledResult<string> => result.status === 'fulfilled') | |
| .map(result => result.value); | |
| return new Response(scanned.join("\n\n")); | |
| } |
🤖 Prompt for AI Agents
In apps/web/src/app/llms-full.txt/route.ts around lines 6 to 11, the GET
function lacks error handling for failures in getLLMText calls. Modify the code
to catch errors for each page processing individually, for example by wrapping
getLLMText calls in try-catch blocks or using Promise.allSettled, so that a
failure in processing one page does not cause the entire request to fail. Return
the successfully processed pages while handling or logging errors gracefully.
| export async function getLLMText(page: InferPageType<typeof source>) { | ||
| const processed = await processor.process({ | ||
| path: page.data._file.absolutePath, | ||
| value: page.data.content, | ||
| }); | ||
|
|
||
| return `# ${page.data.title} | ||
| URL: ${page.url} | ||
| ${page.data.description} | ||
| ${processed.value}`; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling for remark processor failures.
The processor.process call could potentially fail with malformed MDX content. Consider wrapping it in a try-catch block to handle processing errors gracefully.
export async function getLLMText(page: InferPageType<typeof source>) {
- const processed = await processor.process({
- path: page.data._file.absolutePath,
- value: page.data.content,
- });
+ try {
+ const processed = await processor.process({
+ path: page.data._file.absolutePath,
+ value: page.data.content,
+ });
+ } catch (error) {
+ console.warn(`Failed to process page ${page.url}:`, error);
+ return `# ${page.data.title}
+URL: ${page.url}
+${page.data.description}
+[Content processing failed]`;
+ }
return `# ${page.data.title}
URL: ${page.url}
${page.data.description}
${processed.value}`;
}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In apps/web/src/lib/get-llm-text.ts around lines 14 to 26, the call to
processor.process may throw errors if the MDX content is malformed. Wrap the
processor.process call in a try-catch block to catch any exceptions. In the
catch block, handle the error gracefully by logging it or returning a fallback
value to prevent the function from crashing.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/cli/src/prompts/addons.ts (2)
78-121: LGTM with minor suggestion!The refactor to grouped addon selection is well-implemented. The logic correctly categorizes addons, filters empty groups, and maintains compatibility checking.
Consider removing or documenting the commented options (
groupSpacing,selectableGroups) to clarify the intended UI behavior.- // groupSpacing: 1, - selectableGroups: false, + selectableGroups: false,
135-178: LGTM with minor suggestion!The grouped addon selection logic is consistently implemented. The early return when no addons are available improves UX by avoiding empty prompts.
Same suggestion as above - consider removing or documenting the commented
groupSpacingoption.- // groupSpacing: 1, - selectableGroups: false, + selectableGroups: false,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/cli/src/prompts/addons.ts(2 hunks)apps/web/src/lib/constant.ts(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/src/lib/constant.ts
🔇 Additional comments (3)
apps/cli/src/prompts/addons.ts (3)
1-1: LGTM!The addition of
groupMultiselectimport is necessary for the new grouped addon selection UI.
16-63: LGTM!The refactor from if-else chain to switch statement improves readability and maintainability. The new addon cases (oxlint, ultracite, fumadocs) are properly defined with appropriate labels and descriptions.
65-69: LGTM!The addon categorization is logical and user-friendly. Documentation tools, linting tools, and other utilities are properly grouped for better UX.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.changeset/sad-months-drop.md (1)
5-9: Consider converting the free-form sentences into a concise bullet list for clearer release notesThe body reads as three short, un-punctuated sentences. Converting them into a bulleted list (or adding periods) improves readability in the autogenerated changelog.
-Added addons: fumadocs, ultracite, oxlint - -Added bunfig.toml with isolated linker - -Grouped addon prompts +• Added addons: fumadocs, ultracite, oxlint +• Added bunfig.toml with isolated linker +• Grouped addon prompts
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.changeset/sad-months-drop.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.changeset/sad-months-drop.md
[grammar] ~5-~5: Ensure spelling is correct
Context: ...create-better-t-stack": minor --- Added addons: fumadocs, ultracite, oxlint Added bun...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🔇 Additional comments (1)
.changeset/sad-months-drop.md (1)
2-2: Double-check the package scope in the headerThe changeset bumps
"create-better-t-stack"tominor. If other workspace packages were touched by the new addon logic, list them as well to avoid version skew.
closes: #415 #354
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Chores
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Chores