feat: add Bun support

[sujitaw]

What

• added bun support for project as an alternative to pnpm

---

Important

Add Bun support, refactor encryption logic, and simplify session error handling.

• Bun Support:
  • Replaces node:22-alpine with oven/bun:1.3.3-alpine in Dockerfile for both build and production stages.
  • Updates package.json scripts to use bun for dev, build, and start.
  • Adds @types/bun to devDependencies in package.json.
• Encryption Refactor:
  • Replaces crypto-js with native crypto module in encryption.ts.
  • Implements evpBytesToKey() for key derivation.
  • Updates passwordEncryption() to use AES-256-CBC with OpenSSL-compatible output.
• Session Management:
  • Simplifies error handling in generateAccessToken() in session.ts by checking resp.ok instead of specific error messages.

^{This description was created by for 02c6741. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 391fd8d in 1 minute and 15 seconds. Click for details.

• Reviewed 1673 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. package.json:134

• Draft comment:
  Consider pinning @types/bun to a specific version instead of using 'latest' to avoid unexpected updates.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

2. package.json:141

• Draft comment:
  Verify that requiring Node >=24 is intentional, especially with Bun support.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

Workflow ID: wflow_Zpp9eagyY3JEr3Ra

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed feec037 in 1 minute and 31 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. package.json:135

• Draft comment:
  Pinning @types/bun to 1.3.3 is good for stability, but consider using a caret (e.g. "^1.3.3") to allow patch updates.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The PR author deliberately changed from "latest" to a pinned version "1.3.3", which suggests they want to lock to a specific version rather than allow automatic updates. The comment is suggesting they use a caret range instead, which would allow patch updates. This is a subjective preference about versioning strategy - there's no "correct" answer here. The author may have intentionally pinned the exact version to avoid any automatic updates (even patches). This is a valid choice, especially for type definitions that can sometimes cause issues. The comment is making an assumption about what the author should want, rather than pointing out a clear bug or issue. The comment could be valid if there's a strong convention in this project to use caret ranges for devDependencies, or if pinning @types packages is known to cause issues. The author might not have considered that patch updates are generally safe. Even if there's a project convention, this is still subjective advice about versioning strategy rather than a clear code issue. The rules state not to make comments unless there's clearly a code change required. Versioning strategy preferences don't meet that bar - both approaches are valid. The author intentionally moved away from "latest" to pin a version, suggesting deliberate version control. This comment should be deleted. It's subjective advice about versioning strategy rather than identifying a clear bug or required code change. The author deliberately pinned the version, and both pinning and using caret ranges are valid approaches.

Workflow ID: wflow_8mQV2lSkx6L1VhjZ

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 98cb125 in 1 minute and 2 seconds. Click for details.

• Reviewed 26 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/utils/session.ts:35

• Draft comment:
  No refresh token triggers logoutUser() but doesn’t stop further execution. Consider returning immediately (e.g. via return or throwing an error) to avoid proceeding without a valid token.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. src/utils/session.ts:67

• Draft comment:
  The catch block logs error but doesn’t enforce logout. Consider triggering logoutUser() (or propagating the error) to prevent silent failures.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. src/utils/session.ts:20

• Draft comment:
  Polling for removal of the 'persist:root' key with setInterval may be unreliable. Consider an event-driven or promise-based mechanism if available.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

4. src/utils/session.ts:10

• Draft comment:
  Consider extracting the hardcoded localStorage key 'persist:root' into a named constant for easier maintenance.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

Workflow ID: wflow_6T4lU7Dgp31Tytsf

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed f6a650d in 1 minute and 44 seconds. Click for details.

• Reviewed 76 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Dockerfile:18

• Draft comment:
  Remove the redundant '--bun' flag in 'RUN bun --bun run build'. Use 'bun run build' instead.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment is about a code change (the build command was modified in the diff). The --bun flag tells Bun to use its own runtime instead of Node.js compatibility mode. Whether this is "redundant" depends on the specific needs of the Next.js build process. The PR author may have intentionally included --bun for performance or compatibility reasons. Without strong evidence that this flag is actually redundant or harmful, this seems like a speculative suggestion. The comment assumes the author made a mistake, but they may have deliberately chosen to use the --bun flag. This falls into the category of "suggesting the author double-check" or making assumptions about their intentions without clear evidence of an error. The --bun flag might be intentionally included for specific runtime behavior or performance benefits. Without documentation or clear evidence that it's redundant, I'm making an assumption about the author's intent. The build might actually require or benefit from this flag. While the --bun flag might have a purpose, it's also possible it's genuinely redundant when running from a Bun Docker image. However, without strong evidence either way, and given the rule to not make speculative comments or assume the author made mistakes, I should err on the side of deleting this comment. This comment makes an assumption about redundancy without strong evidence. The PR author may have intentionally included the --bun flag for specific runtime behavior. Following the principle that comments should only be kept with strong evidence they're correct, this should be deleted.

2. Dockerfile:9

• Draft comment:
  Confirm that 'bun.lock' is the correct lockfile name (typically 'bun.lockb' is used).
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. Dockerfile:18

• Draft comment:
  Typographical error: The command 'bun --bun run build' appears to include an extra '--bun' flag. Consider revising it to 'bun run build' if that was the intent.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The --bun flag in Bun is a real feature that forces the use of Bun's runtime instead of Node.js. This is particularly useful when building Next.js apps with Bun to ensure consistency. The comment assumes this is a typo, but it's actually a deliberate choice by the PR author. The author migrated from pnpm to bun and likely knows what they're doing. This comment is incorrect because it misidentifies a valid flag as a typo. I might be wrong about the --bun flag being valid. Perhaps it's a deprecated flag or not commonly used. However, even if it were unusual, the PR author clearly made this change intentionally when migrating from pnpm to bun. Even if the --bun flag usage is uncommon, the comment violates the rule about not making speculative comments. The comment says "appears to include an extra flag" and "if that was the intent" - this is speculative language. The --bun flag is documented in Bun's CLI and is a valid option, so this comment is incorrect. This comment should be deleted because --bun is a valid Bun CLI flag, not a typo. The comment incorrectly identifies intentional syntax as an error and uses speculative language ("appears to", "if that was the intent").

Workflow ID: wflow_7HGBuqDpovsK7jtw

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 44bc19a in 1 minute and 50 seconds. Click for details.

• Reviewed 17 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. package.json:10

• Draft comment:
  Dev script: Verify if '--bun' is a valid flag. Typically, Bun runs binaries as 'bun run next dev --turbopack' or 'bun next dev --turbopack'.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the author to verify if a specific flag is valid, which is not allowed according to the rules. It doesn't provide a specific suggestion or point out a clear issue with the code.

2. package.json:11

• Draft comment:
  Build script: Confirm if the '--bun' flag is necessary. The standard Bun usage might not require it.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment violates multiple rules: 1) It asks the PR author to confirm their intention ("Confirm if..."), which is explicitly prohibited. 2) It's speculative about whether the flag is necessary without providing strong evidence that it's wrong. 3) The author clearly made a deliberate change to add Bun support across all scripts, so asking them to confirm seems unnecessary. 4) The comment doesn't provide a clear code change - it just asks a question. The author has made a consistent change across all scripts, suggesting this was intentional and thought through. Perhaps the --bun flag is actually incorrect or redundant, and the comment is trying to point out a real issue. Maybe there's documentation that shows this flag shouldn't be used with "bun run". Even if the flag might be redundant, the comment doesn't provide evidence or a clear directive - it just asks for confirmation. If the tool knew the flag was wrong, it should have stated that definitively with evidence. The phrasing "Confirm if..." is explicitly against the rules. This comment should be deleted because it asks the PR author to confirm their intention rather than providing a clear, actionable code change. It violates the rule against "Verify that..." or "Ensure that..." style comments.

3. package.json:12

• Draft comment:
  Start script: Please double-check the '--bun' flag usage; ensure it aligns with Bun’s documented command syntax.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to double-check the usage of a flag, which violates the rule against asking for confirmation or double-checking. It does not provide a specific suggestion or point out a clear issue.

Workflow ID: wflow_mJqZ7pjHIXMPrbdH

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 2b193b4 in 1 minute and 7 seconds. Click for details.

• Reviewed 22 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. package.json:78

• Draft comment:
  Bump Next to 15.5.7. Ensure this upgrade is intentional and compatible (especially with Bun support) and document any breaking changes if needed.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. package.json:83

• Draft comment:
  Bump React to 19.0.1. Confirm this minor update aligns with project requirements and the upcoming Bun integration.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. package.json:85

• Draft comment:
  Bump React-DOM to 19.0.1. Verify consistency with React and overall compatibility with the rest of the project.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

Workflow ID: wflow_ezVoCUfAGPBXmxOy

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 02c6741 in 49 seconds. Click for details.

• Reviewed 390 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/app/api/server/encryption.ts:3

• Draft comment:
  Consider specifying the encoding explicitly when creating SALTED_MAGIC (e.g., Buffer.from('Salted__', 'utf8')) for clarity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. src/app/api/server/encryption.ts:5

• Draft comment:
  EVP_BytesToKey uses an MD5-based key derivation for OpenSSL compatibility. Note that MD5 is considered weak by modern standards; adding a comment to explain this legacy approach may aid future maintainers.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, explaining the use of MD5 in EVP_BytesToKey for OpenSSL compatibility. It suggests adding a comment for future maintainers, which is not a specific code suggestion or request for a test. It doesn't align with the rules for good comments.

3. src/app/api/server/encryption.ts:27

• Draft comment:
  The check for a server-side environment using 'typeof window !== "undefined"' works in most cases, but ensure this is the intended method to restrict usage to server-only contexts.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

Workflow ID: wflow_vvJazhOW7GDT2ic9

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}