Add Spotless Prettier integration

[phongphongg]

Summary by CodeRabbit

• Chores
  • Improved code formatting infrastructure with enhanced automation and consistency controls
  • Streamlined and reorganized formatting configuration, separating concerns and adding dedicated support for Java code formatting
  • Enhanced the build pipeline to automatically enforce consistent code formatting standards across all project components
  • Added specialized Java code formatting configuration and tooling to the build process for improved code quality

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Walkthrough

This PR migrates Java code formatting from the root Prettier configuration to Spotless with a dedicated Java Prettier config. The root .prettierrc.yaml loses Java/TOML plugins, a .prettierignore file excludes Java sources from root Prettier, and build.gradle.kts integrates Spotless with Java-specific formatting via java.prettierrc.yaml. The CI workflow is simplified to use a single Prettier package.

Changes

Cohort / File(s)	Summary
CI Workflow Update .github/workflows/linter_formatter.yaml	Simplified Prettier dependency to single package (prettier@3.7.3), added --ignore-path .prettierignore flag to Prettier invocation.
Root Prettier Configuration Cleanup .prettierrc.yaml, prettierignore	Removed prettier-plugin-java and prettier-plugin-toml from plugins; removed overrides section for Java/Properties files. New .prettierignore file excludes *.java patterns.
Java-Specific Formatting Setup java.prettierrc.yaml, build.gradle.kts, gradle/libs.versions.toml	Added dedicated java.prettierrc.yaml with prettier-plugin-java and code style rules (printWidth 120, tabWidth 4, etc.). Integrated Spotless Gradle plugin (8.1.0) into build.gradle.kts to apply Java formatting. Added Spotless library declaration to gradle/libs.versions.toml.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• build.gradle.kts Spotless configuration: Verify plugin application logic, config file path resolution, and version compatibility with Spotless 8.1.0.
• Configuration path consistency: Ensure java.prettierrc.yaml location aligns with Spotless configFile reference; test that formatting rules are correctly applied during builds.
• .prettierignore effectiveness: Confirm Java files are properly excluded from root Prettier without conflicting with Spotless enforcement.

Possibly related PRs

• Add Checkstyle code quality enforcement to build system #4: Adds Checkstyle to build.gradle.kts for complementary code quality enforcement alongside Spotless/Prettier.
• Add code quality, linting, and CI configurations #1: Modifies the same CI workflow and root Prettier config, representing prior or related formatting tooling iteration.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The PR title '@coderabbitai' is not descriptive of the changes. The actual objective is to add Spotless Prettier integration, but the title provides no meaningful information.	Rename the title to reflect the primary change, e.g., 'Add Spotless Prettier integration for Java code formatting.'

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch codex/add-spotless-with-prettier-formatting

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d5d9e7a and 8186355.

📒 Files selected for processing (6)

• .github/workflows/linter_formatter.yaml (1 hunks)
• .prettierignore (1 hunks)
• .prettierrc.yaml (0 hunks)
• build.gradle.kts (3 hunks)
• gradle/libs.versions.toml (1 hunks)
• java.prettierrc.yaml (1 hunks)

💤 Files with no reviewable changes (1)

• .prettierrc.yaml

🧰 Additional context used

🧠 Learnings (11)

📓 Common learnings

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: For every significant change or refactoring task, automatically suggest a structured Pull Request Proposal including descriptive title, detailed summary of changes, impact assessment, and verification checklist

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : All generated code must be fully compliant with the project's checkstyle.xml; continuously review and propose refactoring for modularity and scalability

Applied to files:

• build.gradle.kts
• .prettierignore
• java.prettierrc.yaml

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Prioritize using modern Java 25 language features and APIs; consult official Java 25 release documentation

Applied to files:

• build.gradle.kts
• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Proactively identify and replace all deprecated or outdated APIs, libraries, and code constructs with modern Java 25 alternatives

Applied to files:

• build.gradle.kts
• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Create comprehensive Unit Tests for any new or modified code; flag insufficient test coverage and generate necessary tests

Applied to files:

• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Write code compatible with Native Image constraints (GraalVM); minimize runtime reflection and proxies

Applied to files:

• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Operate under the Non-Nullable by Default principle; all type usages (parameters, returns, fields) are non-nullable unless explicitly annotated

Applied to files:

• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Use explicit error handling with specific exception types and Optional over broad catch(Exception e); all log statements must be structured using SLF4J/Log4j 2 with contextual information

Applied to files:

• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Use the Nullable annotation exclusively to mark any type permitted to hold a null value; never use NonNull annotation

Applied to files:

• .prettierignore

📚 Learning: 2025-11-30T03:19:40.814Z

Learnt from: CR
Repo: workastra/server PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-30T03:19:40.814Z
Learning: Applies to **/*.java : Audit all existing legacy code and mark any variables, method parameters, or return types that accept or return null with Nullable annotation

Applied to files:

• .prettierignore

📚 Learning: 2025-11-23T02:13:19.046Z

Learnt from: phongphongg
Repo: workastra/server PR: 2
File: gradle/libs.versions.toml:1-10
Timestamp: 2025-11-23T02:13:19.046Z
Learning: Spring Boot 4.0.0 is compatible with org.graalvm.buildtools.native plugin version 0.11.3, which is the recommended version for Spring Boot 4 native image builds.

Applied to files:

• gradle/libs.versions.toml

⏰ 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: Check

🔇 Additional comments (8)

java.prettierrc.yaml (1)

1-17: Configuration looks solid.

Standard Prettier Java settings with appropriate tab width (4) and line endings (LF). Aligns well with enterprise Java conventions.

.prettierignore (1)

1-2: Correct exclusion patterns.

Properly excludes all Java files (top-level and recursive) from root Prettier runs, delegating Java formatting to Spotless.

gradle/libs.versions.toml (1)

11-11: Spotless library entry looks correct.

Follows the version catalog format. Spotless 8.1.0 is a stable release. Verify compatibility with Spring Boot 4.0.0 and GraalVM 0.11.3 if not already validated.

build.gradle.kts (3)

39-48: Verify against past duplicate configuration concern.

A previous review flagged a duplicate spotless block at root level (lines 43-49) vs. subprojects. The current code shows the configuration only in the subprojects block (lines 39-48). Confirm that any root-level spotless configuration has been removed to comply with DRY principle and avoid redundancy in a multi-project build.

---

41-41: Verify Java file target pattern matches project structure.

The target pattern "src/*/java/**/*.java" uses a wildcard for intermediate directories. This assumes a non-standard structure (e.g., src/{something}/java/...). Verify this captures all Java files in your project. Standard Maven layouts use src/{main,test}/java, which would match via src/*/java/**/*.java, but unconventional structures may need adjustment. If using standard Maven structure, consider documenting or refining the pattern for clarity.

---

43-46: The prettier 3.7.3 and prettier-plugin-java 2.7.7 versions are compatible and properly configured for Spotless 8.1.0.

Both Prettier versions are mutually compatible (prettier-plugin-java 2.7.7 supports Prettier 3.x), and Spotless 8.1.0 explicitly supports this configuration via its prettier() method with devDependencies mapping. No compatibility issues exist.

.github/workflows/linter_formatter.yaml (2)

30-30: Prettier dependency simplified correctly.

Single prettier@3.7.3 aligns with the Spotless configuration in build.gradle.kts. Matches the version specified in the Java formatting setup.

---

32-32: Ignore path flag properly excludes Java files.

The --ignore-path .prettierignore flag correctly delegates Java formatting to Spotless. Root Prettier runs will now skip all Java files as intended by the PR design.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @phongphongg, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a robust code formatting solution by integrating the Spotless Gradle plugin with Prettier. The primary goal is to enforce consistent code style across the entire project, making the codebase more readable and maintainable. By leveraging existing Prettier configurations and defining shared rules, this change streamlines the development workflow and ensures that all code adheres to predefined formatting standards, with checks automatically performed as part of the build process.

Highlights

• Spotless Plugin Integration: The Spotless Gradle plugin has been added to the project, enabling automated code formatting checks and application.
• Prettier Configuration: Prettier is configured within Spotless, utilizing existing project settings and npm dependencies for consistent formatting across various file types.
• Shared Formatting Rules: Common Prettier targets and exclusions are defined and applied across both the root project and all subprojects, ensuring uniform formatting standards.
• Build Lifecycle Integration: The spotlessCheck task has been integrated into the standard check build task, ensuring that formatting compliance is verified during every build.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces Spotless with Prettier for automated code formatting. The implementation is well-structured, defining shared configurations for targets and dependencies, and correctly integrating the formatting check into the build lifecycle. I have one suggestion to improve the maintainability of the Gradle script by removing a redundant configuration block.

[gemini-code-assist]

This spotless configuration block is a duplicate of the one defined at the root level of the project (lines 43-49). In a multi-project Gradle build, subprojects inherit the Spotless configuration from the root project. To adhere to the DRY (Don't Repeat Yourself) principle and improve maintainability, this redundant block should be removed.

[phongphongg]

/gemini review
/gemini summary

[gemini-code-assist]

Hello @phongphongg,

I noticed you've re-issued the /gemini review and /gemini summary commands. Just to clarify, these commands are typically used to initiate a review or summary for a pull request.

I have already provided a summary in my previous comment (Comment ID: 3592154379) and am currently in the process of conducting a full review. My detailed feedback and review comments will be posted shortly. There's no need to re-trigger these commands.

Thank you for your patience!

[phongphongg]

/gemini review

[gemini-code-assist]

Code Review

This pull request effectively refactors the project's code formatting setup by integrating Spotless with Prettier for Java files, which is a great move for ensuring consistent style via the build process. I've identified a critical issue with incorrect dependency versions for Prettier that will break the build, and a high-priority issue regarding the enforcement of formatting checks. I also have a medium-priority suggestion to retain formatting for TOML and properties files, which appears to have been unintentionally removed.