fix: custom fetch for all providers

[louis-jan]

Describe Your Changes

This PR fixes chat/completions requests for other providers to avoid preflight requests.

In this PR, I've also added a DEV flag so that requests will use the built-in fetch method for easier debugging.

Fixes Issues

• Closes bug: Authentication error when using Anthropic API #5689

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Fixes preflight requests for chat/completions by using a custom fetch method and adds a development flag for debugging.

• Behavior:
  • In completion.ts, modified sendCompletion() to use IS_DEV flag to choose between built-in fetch and custom fetch from getServiceHub().providers().fetch().
  • Added IS_DEV flag in vite.config.ts and global.d.ts for environment configuration.
• Configuration:
  • Updated tauri.conf.json to include IS_DEV=true in beforeDevCommand.
  • Updated package.json to use [email protected].
• Misc:
  • Minor formatting changes in completion.ts for better readability.

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to cba7deb in 1 minute and 41 seconds. Click for details.

• Reviewed 99 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 5 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-tauri/tauri.conf.json:9

• Draft comment:
  Addition of the IS_DEV flag is straightforward. Ensure that the consuming code interprets IS_DEV as a boolean (not a non-empty string) to avoid accidental truthiness.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment starts with "Ensure that..." which is a red flag per the rules. It's asking the author to verify something rather than pointing out a clear issue. We can't see the consuming code, so we don't know if there's actually a problem. The comment is speculative about potential issues rather than identifying a concrete problem. The comment raises a valid technical concern about type coercion in environment variables. Maybe there's a known issue in the codebase with boolean env vars. Without seeing the consuming code, we can't verify if this is actually an issue. The rules clearly state we should delete speculative comments and those asking for verification. Delete the comment. It violates multiple rules by being speculative and asking for verification, rather than pointing out a concrete issue.

2. web-app/src/lib/completion.ts:177

• Draft comment:
  Using a ternary with IS_DEV may be risky if IS_DEV isn’t a true boolean. Consider ensuring that IS_DEV is parsed as a boolean to avoid always using the built-in fetch.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While the comment identifies a potential issue with boolean coercion, there's no evidence that IS_DEV is actually problematic. We don't see the definition of IS_DEV, so we can't be sure there's an issue. The suggestion is speculative without seeing how IS_DEV is defined. The current code would work fine as long as IS_DEV follows normal JavaScript truthy/falsy rules. I might be underestimating the importance of explicit boolean conversion. Implicit boolean coercion can sometimes lead to subtle bugs. While explicit boolean conversion is generally good practice, without seeing evidence that IS_DEV actually causes problems, this comment is speculative and violates our rule about not making speculative comments. Delete the comment because it makes a speculative suggestion without clear evidence of an actual problem.

3. web-app/src/lib/completion.ts:187

• Draft comment:
  Overriding fetch for localhost URLs is appropriate to attach custom headers. The formatting change (removing quotes from 'Origin') is stylistic but acceptable.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. web-app/src/types/global.d.ts:25

• Draft comment:
  Adding a global declaration for IS_DEV enhances type safety. Ensure the injected value from the build is a proper boolean.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

5. web-app/vite.config.ts:42

• Draft comment:
  Defining IS_DEV using JSON.stringify may leave it as a string. Consider converting process.env.IS_DEV explicitly to a boolean to avoid truthiness issues (e.g., string 'false' is truthy).
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a Vite config file where define is used for compile-time constants. JSON.stringify is actually the recommended way to handle values in Vite's define option - it's mentioned in Vite's docs. The value will be inserted as-is into the code during build. Even if IS_DEV comes in as a string, JSON.stringify will preserve its string form which is likely intentional for the build process. I might be wrong about the implications of stringified environment variables in Vite's define section. There could be real runtime issues with string vs boolean types. However, this pattern is used consistently throughout the file for all boolean flags, including IS_TAURI and platform checks. If this was a real issue, it would affect all of these flags. The code appears to follow Vite's recommended patterns. The comment should be deleted. It suggests deviating from Vite's standard patterns without strong evidence that there's a real problem.

Workflow ID: wflow_jiW6Ud43jUjIPD37

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

[github-actions]

Barecheck - Code coverage report

Total: 30.77%

Your code coverage diff: -0.01% ▾

Uncovered files and lines

File	Lines
web-app/vite.config.ts	1-8, 11, 13, 15-60, 62, 64-73, 78, 80-91, 93-97
web-app/src/lib/completion.ts	74-85, 156-164, 166, 168-169, 171-173, 175, 177, 180-185, 187-194, 196-206, 209-217, 219, 221-236, 238-259, 275-281, 332, 335-340, 342-345, 361-366, 371-372, 374-396, 399-422, 424-429, 431, 433-453, 455-464, 466-480, 482-485

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed eff85a2 in 40 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. web-app/package.json:82

• Draft comment:
  Bump of token.js-fork from 0.7.23 to 0.7.25 looks appropriate for the custom fetch fix. Ensure that the new version indeed includes the improvements for handling custom fetch (and avoids CORS preflight issues) and that no breaking changes affect other parts of the app.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is related to a dependency change, specifically a version bump of a library. It asks the PR author to ensure that the new version includes certain improvements and that no breaking changes affect other parts of the app. This falls under the rule of not asking the PR author to ensure behavior or test changes, which is not allowed.

Workflow ID: wflow_Dho98j4e2zG3rcv6

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