Skip to content

Conversation

@DaxServer
Copy link
Owner

No description provided.

@coderabbitai
Copy link

coderabbitai bot commented Oct 17, 2025

📝 Walkthrough

Summary by CodeRabbit

  • Chores
    • Replaced ESLint and Prettier with Biome for unified code formatting, linting, and quality checks
    • Updated development scripts to use Biome-based commands for code quality validation
    • Consolidated import statements and refined code style patterns across test files

Walkthrough

Comprehensive migration from ESLint/Prettier tooling to Biome for project-wide linting and formatting. Updates dependencies, removes legacy configurations, adds Biome configuration, consolidates imports across test files, converts several value imports to type-only imports, and applies minor code quality improvements like Number.isNaN and exponentiation operators.

Changes

Cohort / File(s) Summary
ESLint & Prettier Configuration Removal
eslint.config.ts, backend/eslint.config.ts, frontend/eslint.config.ts, prettier.config.ts
Removes all ESLint and Prettier configuration files, including composite configs, parser options, plugin integrations, and formatting rules.
Biome Configuration
.biomeignore, biome.json
Adds Biome ignore patterns for build/dependency files and a comprehensive Biome configuration with VCS settings, file matching, formatting rules (spaces, 2-space indent, line width 100), linting with recommended preset, JavaScript formatter options, JSON formatting, and import organization.
Package Configuration Updates
package.json, backend/package.json, frontend/package.json
Replaces ESLint, Prettier, and related plugin dependencies with @biomejs/biome; updates root-level scripts to use bunx biome for format, lint, and check operations; removes lint/format/preview scripts from frontend.
Type-Only Import Refactors
backend/src/api/project/index.ts, backend/src/plugins/database.ts, backend/src/services/wikibase-clients.ts, frontend/src/features/data-processing/composables/useColumnGeneration.ts, frontend/src/features/wikibase-schema/composables/useSchemaApi.ts, frontend/src/shared/types/index.ts, frontend/src/features/wikibase-schema/stores/schema.store.ts
Converts value imports to type-only imports for types no longer needed at runtime, improving bundle optimization and treeshaking.
Backend Test Import Consolidation
backend/tests/api/_meta_projects.test.ts, backend/tests/api/project/import-file.test.ts, backend/tests/api/project/import.test.ts, backend/tests/api/project/lowercase.test.ts, backend/tests/api/project/project.*.test.ts, backend/tests/constraint-validation.service.test.ts, backend/tests/db.test.ts, backend/tests/error-handler.test.ts, backend/tests/services/*.test.ts, backend/tests/upload/file-processor.test.ts, backend/tests/wikibase-error-handler.test.ts
Moves bun:test imports to file top and removes duplicate imports; consolidates test utilities and module imports. Re-enables commented imports in file-processor.test.ts.
Frontend Test Import Consolidation
frontend/src/features/data-processing/composables/__tests__/*.test.ts, frontend/src/features/wikibase-schema/composables/__tests__/*.test.ts, frontend/src/features/wikibase-schema/stores/__tests__/*.test.ts, frontend/src/shared/stores/__tests__/drag-drop.store.test.ts
Moves bun:test imports to top of test files and removes duplicate imports; reorganizes test setup utilities.
Test Setup Refactors
frontend/src/features/wikibase-schema/composables/__tests__/useStatementDataTypeValidation.test.ts, frontend/src/features/wikibase-schema/composables/__tests__/useStatementEditor.test.ts
Replaces beforeEach hooks with inline constant fixtures (testProperties, testColumns, testProperty, initialStatement) for test setup.
Code Quality Improvements
backend/src/services/commons-upload.ts, backend/src/utils/wikibase-error-handler.ts
Replaces Math.pow(base, exponent) with exponentiation operator base ** exponent for backoff calculations.
NaN Detection Improvements
backend/src/services/constraint-validation.service.ts, frontend/src/features/wikibase-schema/components/SchemaSelector.vue
Replaces global isNaN() with Number.isNaN() for stricter NaN validation.
Minor Code Style & Import Refactors
frontend/src/features/data-processing/composables/useColumnDataTypeIndicators.ts, frontend/src/features/wikibase-schema/components/ValidationDisplay.vue, frontend/src/core/plugins/api.ts, frontend/src/core/router/router.ts, frontend/src/main.ts, frontend/src/shared/components/Sidebar.vue, frontend/vite.config.ts, backend/src/services/file-processor/file-buffer-extractor.ts, backend/src/services/file-processor/metadata-builder.ts, backend/src/services/file-processor/multiple-files-processor.ts, backend/src/types/error-handler.ts
String concatenation to template literals, import reordering, variable immutability (const instead of let), import consolidation, Date.now() instead of new Date().getTime(), and internal method call refactoring (this.createErrorWithData to ClassName.createErrorWithData).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Rationale: While the PR contains many repetitive import consolidations (lower individual effort), the heterogeneity and scope are significant. Key concerns: (1) Biome configuration correctness and completeness requires careful verification; (2) type-only import conversions must ensure no runtime dependencies are broken; (3) test setup refactors (particularly fixture inlining) need validation; (4) approximately 60+ files touched with mixed patterns (config removal, imports, code quality). The repetitive nature of test import moves reduces per-file effort, but overall complexity and distributed changes demand thorough review.

Possibly related PRs

  • chore: update dependencies #177: Directly overlaps with this PR's modifications to backend/eslint.config.ts, package.json scripts, and removal of ESLint/Prettier dependencies.
  • chore: fix more tests #152: Modifies the same linting and configuration files (eslint.config.ts, test import setups) with related tooling changes.
  • chore: sanitize eslint and prettier #149: Conflicts with this PR's approach to lint/format configuration, modifying the same ESLint and Prettier config files in divergent ways.

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Description Check ❓ Inconclusive The author did not provide a pull request description, making it impossible to verify whether the description is related to the changeset as required by the passing criterion. While the description is not "completely off-topic" (since it doesn't exist), there is also no content to confirm it relates to the changeset in any way. The absence of a description leaves insufficient information to conclusively determine whether this check meets the specified criteria. Add a pull request description explaining the migration objectives, such as why Biome was chosen over ESLint/Prettier, any breaking changes, dependencies affected, and steps for developers to be aware of during this transition. Even a brief summary of the migration scope would satisfy this check.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The PR title "feat: migrate to biomejs" is directly aligned with the main objective of this changeset. The bulk of the changes involve removing ESLint and Prettier configurations across the codebase, adding a new Biome configuration file (biome.json and .biomeignore), updating dependencies in package.json files, and modifying scripts to use Biome commands for linting and formatting. The title clearly and concisely communicates the primary change without any vague terms, noise, or misleading information.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ 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 biome

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

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (14)
backend/tests/upload/file-processor.test.ts (1)

261-332: Remove duplicate describe block and consolidate tests.

Lines 261–282 and lines 285–306 are duplicate "image metadata extraction" describe blocks with identical test content. The first test in each block ("should extract image dimensions and metadata for JPEG") is a carbon copy. This duplication inflates test execution time and creates maintenance burden.

Consolidate both describe blocks into a single one, placing the new test "should handle non-image files gracefully" (lines 308–331) in the deduplicated block.

Apply this diff to remove the duplicate block:

  })

  describe('image metadata extraction', () => {
    test('should extract image dimensions and metadata for JPEG', () => {
      const fileInput: FileInput = {
        type: 'filepath',
        path: testFilePath,
      }

      expect(processFile(fileInput)).resolves.toMatchObject({
        metadata: {
          filename: 'test-image.jpg',
          mimeType: 'image/jpeg',
          extension: '.jpg',
          imageMetadata: expect.objectContaining({
            width: expect.any(Number),
            height: expect.any(Number),
            format: expect.any(String),
          }),
        },
        isValid: true,
        errors: [],
      })
    })

-   describe('image metadata extraction', () => {
-     test('should extract image dimensions and metadata for JPEG', () => {
-       const fileInput: FileInput = {
-         type: 'filepath',
-         path: testFilePath,
-       }
-
-       expect(processFile(fileInput)).resolves.toMatchObject({
-         metadata: {
-           filename: 'test-image.jpg',
-           mimeType: 'image/jpeg',
-           extension: '.jpg',
-           imageMetadata: expect.objectContaining({
-             width: expect.any(Number),
-             height: expect.any(Number),
-             format: expect.any(String),
-           }),
-         },
-         isValid: true,
-         errors: [],
-       })
-     })

    test('should handle non-image files gracefully', async () => {
      const textFilePath = join(tempDir, 'test.txt')
      await Bun.write(textFilePath, 'This is a text file')

      const fileInput: FileInput = {
        type: 'filepath',
        path: textFilePath,
      }

      const customOptions = {
        allowedMimeTypes: ['text/plain', 'application/octet-stream'],
        allowedExtensions: ['.txt'],
      }

      expect(processFile(fileInput, customOptions)).resolves.toMatchObject({
        metadata: {
          filename: 'test.txt',
          mimeType: 'application/octet-stream',
          extension: '.txt',
        },
        isValid: true,
        errors: [],
      })
    })
-   })
  })
})
backend/src/services/file-processor/multiple-files-processor.ts (1)

22-24: Consider safer handling of potentially undefined path.

The non-null assertion operator ! on line 23 assumes that when type === 'filepath', the path property is always defined. If the data is malformed or doesn't match the expected type contract, this will cause a runtime error during error handling.

Apply this diff to handle the case more defensively:

         filename:
           uploadFiles[index]?.type === 'filepath'
-            ? basename(uploadFiles[index].path!)
+            ? (uploadFiles[index].path ? basename(uploadFiles[index].path) : 'unknown')
             : uploadFiles[index]?.filename || 'unknown',
frontend/src/features/wikibase-schema/composables/__tests__/useStatementConfig.test.ts (1)

97-109: Test expects wrong source shape for default 'column' type.

Earlier you assert default type is 'column' and source is an object; here you set a string and expect a string. Make the type 'constant' (or update expectations to an object for 'column').

Apply this minimal fix:

   it('should handle source value correctly', () => {
-    const { currentStatement, sourceValue } = useStatementConfig()
+    const { currentStatement, sourceValue } = useStatementConfig()
+    // Use a type where the underlying source is a string
+    currentStatement.value.value.type = 'constant'
 
     // Set string source
     sourceValue.value = 'test_value'
     expect(currentStatement.value.value.source).toBe('test_value')
     expect(sourceValue.value).toBe('test_value')
 
     // Clear source
     sourceValue.value = ''
     expect(currentStatement.value.value.source).toBe('')
     expect(sourceValue.value).toBe('')
   })

Alternative: keep 'column' and assert object equality:

  • expect(currentStatement.value.value.source).toEqual({ columnName: 'test_value', dataType: 'VARCHAR' })
  • After clear: expect(...).toEqual({ columnName: '', dataType: 'VARCHAR' })
backend/tests/services/lowercase-conversion.service.test.ts (1)

42-47: Await or return Promise-based expectations; current assertions may be skipped.

The tests use expect(...).resolves/...rejects... without await or returning the Promise. The test can finish before the assertion runs, causing false positives. Use await expect(...)... (or return expect(...)...).

Apply these fixes:

@@ first test
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'name',
         }),
       ).resolves.toBe(4)

@@ "empty strings"
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(1)

@@ "non-existent column"
-      expect(
+      await expect(
         service.performOperation({ table: 'test', column: 'nonexistent_col' }),
       ).rejects.toThrowError(`Column 'nonexistent_col' not found in table 'test'`)

@@ "non-existent table"
-    test('should handle non-existent table', () => {
-      expect(
+    test('should handle non-existent table', async () => {
+      await expect(
         service.performOperation({ table: 'nonexistent_table', column: 'text_col' }),
       ).rejects.toThrow()
     })

@@ "no rows need conversion"
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(0)

@@ "special characters and numbers"
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(7)

@@ "unicode characters"
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(5)

References: Bun async tests and expect matchers; using async/await (and returning Promises) ensures execution order, similar to Jest’s guidance. Based on docs. (bun.com)

Also applies to: 79-85, 141-144, 146-150, 172-178, 202-208, 242-248

backend/tests/services/trim-whitespace.service.test.ts (1)

63-67: Add missing async keywords and await on Promise matchers in tests.

The review comment is correct. Six test functions use .rejects or .resolves matchers without proper async/await handling, which can cause race conditions and false test passes:

  • Lines 63-67: non-existent column test
  • Lines 69-73: non-existent table test
  • Lines 88-102: INTEGER, DOUBLE, BOOLEAN, DATE column tests

All proposed fixes in the patch are accurate and necessary for reliable test execution.

backend/tests/services/uppercase-conversion.service.test.ts (1)

41-48: Await/return Promise-based assertions; fix non-async tests using .rejects.

Un-awaited .resolves/.rejects can yield false positives and race with subsequent DB reads.

Apply this patch:

-      expect(
-        service.performOperation({
-          table: 'test',
-          column: 'name',
-        }),
-      ).resolves.toBe(4)
+      await expect(
+        service.performOperation({
+          table: 'test',
+          column: 'name',
+        }),
+      ).resolves.toBe(4)

-    test('should handle empty strings', async () => {
+    test('should handle empty strings', async () => {
       ...
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(1)

-    test('should handle non-existent column', async () => {
+    test('should handle non-existent column', async () => {
       ...
-      expect(
+      await expect(
         service.performOperation({ table: 'test', column: 'nonexistent_col' }),
       ).rejects.toThrowError(`Column 'nonexistent_col' not found in table 'test'`)

-    test('should handle non-existent table', () => {
-      expect(
+    test('should handle non-existent table', async () => {
+      await expect(
         service.performOperation({ table: 'nonexistent_table', column: 'text_col' }),
       ).rejects.toThrow()

-    test('should return 0 when no rows need conversion', async () => {
+    test('should return 0 when no rows need conversion', async () => {
       ...
-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(0)

-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(7)

-      expect(
+      await expect(
         service.performOperation({
           table: 'test',
           column: 'text_col',
         }),
       ).resolves.toBe(5)

Also applies to: 78-85, 141-144, 146-150, 171-178, 201-208, 241-248

frontend/src/features/wikibase-schema/stores/schema.store.ts (4)

16-18: Ref type is used but not imported.

const statements: Ref<...> needs Ref imported from vue to type-check.

Apply:

-import { computed, ref } from 'vue'
+import { computed, ref } from 'vue'
+import type { Ref } from 'vue'

Also applies to: 30-31


391-399: Non-null assertions on statements1 can throw; add guards and init arrays.

Several places assume presence of statements1[statementId], qualifiers, or references. If out of sync, this will crash.

Suggested pattern (apply similarly across touched blocks):

@@ updateStatementRank
-  const statement = statements.value.find((s) => s.id === statementId)
-  if (statement) {
-    statement.rank = rank
-    statements1.value[statementId]!.rank = rank
-    markDirty()
-  }
+  const statement = statements.value.find((s) => s.id === statementId)
+  const s1 = statements1.value[statementId]
+  if (!statement || !s1) return
+  statement.rank = rank
+  s1.rank = rank
+  markDirty()
@@ addNewQualifier
-  statements1.value[statementId]!.qualifiers?.push({
+  const s1 = statements1.value[statementId]
+  if (!s1) return
+  if (!s1.qualifiers) s1.qualifiers = []
+  s1.qualifiers.push({
@@ addSnakToReference
-  const statement = statements1.value[statementId]
-  if (!statement?.references) return
-  const reference = statement.references.find((r) => r.id === referenceId)
+  const s1 = statements1.value[statementId]
+  if (!s1) return
+  if (!s1.references) s1.references = []
+  const reference = s1.references.find((r) => r.id === referenceId)
   if (!reference) return
@@ removeSnakFromReference
-  const statement = statements1.value[statementId]
-  if (!statement?.references) return
-  const reference = statement.references.find((r) => r.id === referenceId)
+  const s1 = statements1.value[statementId]
+  if (!s1?.references) return
+  const reference = s1.references.find((r) => r.id === referenceId)
   if (!reference) return

This avoids runtime crashes and ensures arrays exist before mutation.

Also applies to: 401-409, 411-419, 421-429, 338-363, 365-377, 205-224, 254-260


386-389: removeStatement1 leaves statements stale.

Removes from map only; array still contains the statement → inconsistent state.

Apply:

 const removeStatement1 = (statementId: UUID) => {
-  delete statements1.value[statementId]
+  delete statements1.value[statementId]
+  const idx = statements.value.findIndex((s) => s.id === statementId)
+  if (idx !== -1) statements.value.splice(idx, 1)
   markDirty()
 }

15-16: Fix the invalid UUID type import from 'crypto'—this will cause a compilation error.

The Node.js crypto module does not export a UUID type, only randomUUID() which returns a string. The import at line 15 is invalid and will fail to compile. Since UUID is used throughout the file and in shared types, replace the broken import with a local type alias:

-import type { UUID } from 'crypto'
+type UUID = string

Alternatively, if the project already has or plans to have a centralized UUID type elsewhere, import from that location instead.

frontend/src/features/wikibase-schema/components/SchemaSelector.vue (1)

49-55: Bug: toLocaleDateString ignores time options; use toLocaleString.

Time fields (hour, minute) are ignored by toLocaleDateString. This likely drops time from the UI.

-    return date.toLocaleDateString('en-US', {
+    return date.toLocaleString('en-US', {
       year: 'numeric',
       month: 'short',
       day: 'numeric',
       hour: '2-digit',
       minute: '2-digit',
     })

Optional: set timeZone or timeStyle: 'short' if you need consistent cross-locale rendering.

backend/tests/db.test.ts (2)

56-57: Await the promise when using .resolves.

Without await, the test may pass before the assertion runs.

-      expect(closeDb()).resolves.toBeUndefined()
+      await expect(closeDb()).resolves.toBeUndefined()

93-100: Await the promise when using .rejects.

Ensure the rejection assertion is awaited to avoid false positives.

-    expect(
+    await expect(
       db.run(`INSERT INTO _meta_wikibase_schema (id, project_id, wikibase) VALUES (?, ?, ?)`, [
         Bun.randomUUIDv7(),
         '22222222-2222-4222-8222-222222222222',
         'wikibase',
       ]),
-    ).rejects.toThrow()
+    ).rejects.toThrow()
backend/package.json (1)

13-13: Fix the lint script to use Biome instead of ESLint.

The lint script still references eslint, but ESLint was removed from devDependencies (line 33). This will cause the script to fail when executed. Update the script to use Biome instead.

Apply this diff to fix the script:

-    "lint": "eslint",
+    "lint": "biome lint",
🧹 Nitpick comments (15)
backend/tests/api/project/project.trim-whitespace.test.ts (1)

53-53: Consider using path.join for cross-platform compatibility.

String concatenation with a hard-coded forward slash works in most environments, but using path.join(tmpdir(), 'test-trim-whitespace-data.json') would be more robust across platforms.

Apply this diff:

+import { join } from 'node:path'
-const tempFilePath = tmpdir() + '/test-trim-whitespace-data.json'
+const tempFilePath = join(tmpdir(), 'test-trim-whitespace-data.json')
frontend/src/shared/stores/__tests__/drag-drop.store.test.ts (2)

2-2: Avoid frontend → backend type import

Importing WikibaseDataType from @backend/... couples the frontend test to backend internals. Prefer moving the type to a shared package (e.g., @shared/types/...) or re-export it from an existing shared module the frontend already uses.


303-317: Tighten the test table typing for dataType

Use the source type instead of string to prevent drift if ColumnInfo['dataType'] changes.

Apply:

-const testCases: { dataType: string; expectedTargets: WikibaseDataType[] }[] = [
+const testCases: { dataType: ColumnInfo['dataType']; expectedTargets: WikibaseDataType[] }[] = [
frontend/src/features/wikibase-schema/composables/__tests__/useStatementConfig.test.ts (3)

157-159: Avoid setTimeout(0) flakiness when waiting for auto‑save.

Prefer Vue’s microtask flush for deterministic tests.

Apply:

-    await new Promise((resolve) => setTimeout(resolve, 0))
+    await nextTick()

And add the import near the top:

+import { nextTick } from 'vue'

29-29: Drop unnecessary type cast in assertion.

The cast is a compile‑time no‑op and inconsistent with Line 132.

-expect(currentStatement.value.rank).toBe('normal' as StatementRank)
+expect(currentStatement.value.rank).toBe('normal')

34-36: Length-only assertions can be brittle.

If these lists are expected to evolve, assert required members instead of fixed lengths (e.g., expect.arrayContaining([...])).

backend/tests/services/replace-operation.alter-table.service.test.ts (1)

120-121: Differentiate duplicate test names for clarity (optional).

Two cases are labeled “JSON”; consider renaming to disambiguate in reports.

-      name: 'JSON',
+      name: 'JSON (quoted)',
@@
-      name: 'JSON',
+      name: 'JSON (substring)',

Also applies to: 145-146

backend/tests/api/project/project.replace.test.ts (1)

25-26: Use path.join for cross‑platform temp file path.

String concatenation can break on Windows. Prefer Node’s path utilities.

+import { join } from 'node:path'
@@
-const tempFilePath = tmpdir() + '/test-data.json'
+const tempFilePath = join(tmpdir(), 'test-data.json')
backend/src/services/constraint-validation.service.ts (1)

327-336: Good: use Number.isNaN to avoid coercion. Add robust numeric extraction for object values.

Values may arrive as Snak-like objects (e.g., quantity/time). Consider normalizing before checks.

-    const numericValue = typeof value === 'number' ? value : parseFloat(value)
-    if (Number.isNaN(numericValue)) {
+    const toNumber = (v: any): number => {
+      if (typeof v === 'number') return v
+      if (typeof v === 'string') return parseFloat(v)
+      // common Wikibase shapes
+      if (v?.type === 'quantity' && v?.value?.amount) return parseFloat(v.value.amount)
+      if (v?.value?.amount) return parseFloat(v.value.amount)
+      return Number.NaN
+    }
+    const numericValue = toNumber(value)
+    if (Number.isNaN(numericValue)) {

If you prefer, I can add targeted unit tests covering quantity/time Snaks.

backend/tests/constraint-validation.service.test.ts (2)

67-78: Strengthen assertion for single-value violation.

toBeGreaterThanOrEqual(0) can pass when no violation occurs. Use a strict check to ensure the constraint is enforced.

-      // Should have violations for single value constraint
-      expect(result.violations.length).toBeGreaterThanOrEqual(0)
+      // Should have violations for single value constraint
+      expect(result.violations.length).toBeGreaterThan(0)

113-121: Test doesn’t exercise caching.

You’re mocking getPropertyConstraints itself, so the “cache” path isn’t verified. Consider mocking wikibaseService.getProperty instead and asserting it’s called once across two service calls.

frontend/src/features/data-processing/composables/useColumnDataTypeIndicators.ts (1)

138-156: Harden truncation against non-string samples.

Stats code treats null/undefined as possible values; truncation assumes string. Guard/coerce to avoid runtime errors.

Apply within this block:

-  const formatSampleValuesForTooltip = (sampleValues: string[], maxDisplay: number = 5): string => {
+  const formatSampleValuesForTooltip = (sampleValues: (string | null | undefined)[], maxDisplay: number = 5): string => {
@@
-    const truncateValue = (value: string, maxLength: number = 30): string => {
-      return value.length > maxLength ? `${value.substring(0, maxLength)}...` : value
+    const truncateValue = (value: string | null | undefined, maxLength: number = 30): string => {
+      const s = value ?? ''
+      return s.length > maxLength ? `${s.substring(0, maxLength)}...` : s
     }
@@
-    const displayValues = sampleValues.slice(0, maxDisplay).map((val) => truncateValue(val))
+    const displayValues = sampleValues.slice(0, maxDisplay).map((val) => truncateValue(val))
frontend/src/features/wikibase-schema/stores/schema.store.ts (2)

274-281: Default DB column type inconsistency ('string' vs 'VARCHAR').

New reference/qualifier snak sources use dataType: 'string' while elsewhere column defaults are 'VARCHAR'. Standardize to DB type to simplify downstream compatibility logic.

Example:

-          value: {
+          value: {
             type: 'column',
             dataType: 'string',
             source: {
               columnName: '',
-              dataType: 'string',
+              dataType: 'VARCHAR',
             },
           },

Also applies to: 352-359


30-36: Two sources of truth for statements (statements and statements1).

Maintaining both invites drift and requires many sync points.

Consider a single canonical store (e.g., map by id) with derived getters (array view) or centralized mutation helpers to keep them in sync.

Also applies to: 546-571

frontend/src/core/plugins/api.ts (1)

33-37: Optional: avoid creating a new client per call; reuse configured base URL.

api() currently instantiates a fresh client on each call with a hardcoded URL. Consider reusing the instance provided via the plugin or caching by URL to prevent redundant clients and to honor ApiPlugin options.

-export const api = () => {
-  // This will be used by auto-imports, but in components use useApi() instead
-  return treaty<ElysiaApp>('http://localhost:3000').api
-}
+const __apiCache = new Map<string, ReturnType<typeof treaty<ElysiaApp>>>()
+export const api = (baseUrl = 'http://localhost:3000') => {
+  if (!__apiCache.has(baseUrl)) {
+    __apiCache.set(baseUrl, treaty<ElysiaApp>(baseUrl))
+  }
+  return __apiCache.get(baseUrl)!.api
+}
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ba75c3e and a45b78d.

⛔ Files ignored due to path filters (1)
  • bun.lock is excluded by !**/*.lock
📒 Files selected for processing (77)
  • .biomeignore (1 hunks)
  • backend/eslint.config.ts (0 hunks)
  • backend/package.json (1 hunks)
  • backend/src/api/project/index.ts (3 hunks)
  • backend/src/plugins/database.ts (1 hunks)
  • backend/src/services/commons-upload.ts (1 hunks)
  • backend/src/services/constraint-validation.service.ts (2 hunks)
  • backend/src/services/file-processor/file-buffer-extractor.ts (1 hunks)
  • backend/src/services/file-processor/metadata-builder.ts (1 hunks)
  • backend/src/services/file-processor/multiple-files-processor.ts (1 hunks)
  • backend/src/services/wikibase-clients.ts (1 hunks)
  • backend/src/types/error-handler.ts (16 hunks)
  • backend/src/utils/wikibase-error-handler.ts (1 hunks)
  • backend/tests/api/_meta_projects.test.ts (1 hunks)
  • backend/tests/api/project/import-file.test.ts (1 hunks)
  • backend/tests/api/project/import.test.ts (2 hunks)
  • backend/tests/api/project/lowercase.test.ts (1 hunks)
  • backend/tests/api/project/project.create.test.ts (1 hunks)
  • backend/tests/api/project/project.delete.test.ts (1 hunks)
  • backend/tests/api/project/project.get-all.test.ts (1 hunks)
  • backend/tests/api/project/project.get.test.ts (1 hunks)
  • backend/tests/api/project/project.import-csv.test.ts (1 hunks)
  • backend/tests/api/project/project.import-file.test.ts (1 hunks)
  • backend/tests/api/project/project.replace.test.ts (1 hunks)
  • backend/tests/api/project/project.trim-whitespace.test.ts (1 hunks)
  • backend/tests/api/project/project.wikibase.test.ts (1 hunks)
  • backend/tests/api/project/uppercase.test.ts (1 hunks)
  • backend/tests/constraint-validation.service.test.ts (1 hunks)
  • backend/tests/db.test.ts (1 hunks)
  • backend/tests/error-handler.test.ts (1 hunks)
  • backend/tests/services/lowercase-conversion.service.test.ts (1 hunks)
  • backend/tests/services/replace-operation.alter-table.service.test.ts (1 hunks)
  • backend/tests/services/replace-operation.service.test.ts (1 hunks)
  • backend/tests/services/trim-whitespace.service.test.ts (1 hunks)
  • backend/tests/services/uppercase-conversion.service.test.ts (1 hunks)
  • backend/tests/upload/file-processor.test.ts (1 hunks)
  • backend/tests/wikibase-error-handler.test.ts (1 hunks)
  • biome.json (1 hunks)
  • eslint.config.ts (0 hunks)
  • frontend/eslint.config.ts (0 hunks)
  • frontend/package.json (0 hunks)
  • frontend/src/core/plugins/api.ts (1 hunks)
  • frontend/src/core/router/router.ts (1 hunks)
  • frontend/src/features/data-processing/composables/__tests__/useColumnDataTypeIndicators.test.ts (1 hunks)
  • frontend/src/features/data-processing/composables/__tests__/useColumnGeneration.test.ts (1 hunks)
  • frontend/src/features/data-processing/composables/__tests__/useDataTypeCompatibility.test.ts (1 hunks)
  • frontend/src/features/data-processing/composables/useColumnDataTypeIndicators.ts (1 hunks)
  • frontend/src/features/data-processing/composables/useColumnGeneration.ts (1 hunks)
  • frontend/src/features/wikibase-schema/components/SchemaSelector.vue (2 hunks)
  • frontend/src/features/wikibase-schema/components/ValidationDisplay.vue (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/usePropertySelection.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useReferenceValueMapping.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useSchemaCompletenessIntegration.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useSchemaCompletenessValidation.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useSchemaSelection.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useSchemaValidationUI.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useStatementConfig.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useStatementDataTypeValidation.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useStatementEditor.test.ts (2 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useStatementValidationDisplay.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useValidation.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useValidationCore.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useValidationErrors.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/__tests__/useValueMapping.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/composables/useSchemaApi.ts (1 hunks)
  • frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/stores/__tests__/validation-rules.store.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/stores/__tests__/validation.store.test.ts (1 hunks)
  • frontend/src/features/wikibase-schema/stores/schema.store.ts (1 hunks)
  • frontend/src/main.ts (1 hunks)
  • frontend/src/shared/components/Sidebar.vue (0 hunks)
  • frontend/src/shared/stores/__tests__/drag-drop.store.test.ts (1 hunks)
  • frontend/src/shared/types/index.ts (1 hunks)
  • frontend/vite.config.ts (1 hunks)
  • package.json (2 hunks)
  • prettier.config.ts (0 hunks)
💤 Files with no reviewable changes (6)
  • frontend/src/shared/components/Sidebar.vue
  • eslint.config.ts
  • prettier.config.ts
  • frontend/eslint.config.ts
  • backend/eslint.config.ts
  • frontend/package.json
🧰 Additional context used
🧬 Code graph analysis (3)
backend/src/types/error-handler.ts (1)
backend/src/types/error-schemas.ts (2)
  • ApiErrors (20-26)
  • ApiErrors (27-27)
frontend/src/features/wikibase-schema/composables/__tests__/useStatementEditor.test.ts (3)
frontend/src/shared/types/wikibase-schema.ts (1)
  • ColumnInfo (98-104)
backend/src/api/project/project.wikibase.ts (2)
  • PropertyReference (35-35)
  • ValueMapping (55-55)
backend/src/types/wikibase-schema.ts (2)
  • StatementRank (19-23)
  • StatementRank (24-24)
frontend/src/features/wikibase-schema/composables/__tests__/useStatementDataTypeValidation.test.ts (2)
backend/src/api/project/project.wikibase.ts (1)
  • PropertyReference (35-35)
frontend/auto-imports.d.ts (1)
  • PropertyReference (375-375)
🔇 Additional comments (80)
frontend/src/features/data-processing/composables/__tests__/useDataTypeCompatibility.test.ts (1)

1-3: Import consolidation follows best practices.

The top-level consolidation of bun:test imports and proper use of the type keyword for ColumnInfo are clean and correct. This aligns well with the Biome migration pattern being applied across the codebase.

frontend/src/features/data-processing/composables/__tests__/useColumnGeneration.test.ts (1)

1-1: Import consolidation aligns with Biome migration best practices.

Consolidating bun:test imports at the top of the file follows standard conventions and removes duplication. The import organization (test utilities → type imports → composable imports) is clean and idiomatic.

backend/src/services/file-processor/metadata-builder.ts (1)

1-5: Import consolidation looks good.

Moving extname to the top alongside other module imports improves consistency and readability. The change is a clean organizational improvement with no behavioral impact.

frontend/src/features/wikibase-schema/stores/__tests__/validation.store.test.ts (1)

1-1: LGTM!

Import consolidation successfully moves the bun:test import to the top of the file, removing duplication. The destructured test utilities are all correctly referenced throughout the test suite. This change aligns with Biome's import organization conventions.

frontend/src/features/data-processing/composables/__tests__/useColumnDataTypeIndicators.test.ts (1)

1-3: Well-organized imports aligned with Biome migration.

The consolidation of the bun:test import at the top (line 1) follows best practices, and the type-only import on line 3 is already using the proper import type keyword. The import organization is clean and consistent.

backend/tests/upload/file-processor.test.ts (1)

5-7: Imports correctly re-enabled and use proper type syntax.

Lines 5-7 appropriately uncomment imports that are actively used throughout the test suite. Line 7 correctly uses the type keyword for type-only imports (FileInput, FileValidationOptions), following TypeScript best practices to ensure these types don't leak into the runtime bundle.

frontend/src/features/wikibase-schema/composables/__tests__/useReferenceValueMapping.test.ts (1)

1-1: LGTM! Import consolidation improves code organization.

Consolidating the bun:test import at the top of the file eliminates duplication and aligns with standard practices for organizing imports.

backend/tests/services/replace-operation.service.test.ts (1)

1-1: LGTM! Import consolidation improves code cleanliness.

Consolidating all bun:test imports into a single statement is a best practice that improves readability and aligns well with the biomejs migration.

frontend/src/features/wikibase-schema/composables/__tests__/useSchemaSelection.test.ts (1)

1-1: LGTM! Import consolidation improves code quality.

Consolidating all bun:test imports into a single statement follows best practices and aligns with the Biome migration objectives.

frontend/src/features/wikibase-schema/composables/__tests__/useStatementValidationDisplay.test.ts (1)

1-1: LGTM! Clean import consolidation.

The bun:test import has been properly moved to the top of the file, consolidating all test utilities in a single import statement. This aligns with Biome's import ordering rules and improves code organization without any functional impact.

frontend/src/features/wikibase-schema/composables/__tests__/useValidationCore.test.ts (1)

1-1: LGTM! Clean import consolidation.

The consolidated bun:test import is properly structured, and all imported functions are used throughout the test suite. This refactor aligns well with the Biome migration objective.

backend/tests/api/project/project.trim-whitespace.test.ts (1)

1-2: LGTM! Import consolidation improves code organization.

Moving the bun:test and node:os imports to the top of the file follows standard ESM practices and aligns with the Biome migration objectives.

backend/src/services/file-processor/file-buffer-extractor.ts (1)

1-1: LGTM! Clean import consolidation.

The top-level import of basename and its usage to extract the filename from the filepath is correct. The guard on lines 13-15 ensures the path is defined before use.

Also applies to: 19-19

backend/src/services/file-processor/multiple-files-processor.ts (1)

1-1: LGTM! Import consolidation aligns with Biome standards.

The top-level import of basename improves code organization and consistency across the file-processor module.

backend/src/services/commons-upload.ts (1)

96-96: LGTM! Modern exponentiation operator.

The change from Math.pow(2, attempt) to 2 ** attempt is a stylistic improvement using the modern exponentiation operator, with identical behavior.

backend/src/utils/wikibase-error-handler.ts (1)

220-220: LGTM! Consistent exponentiation operator usage.

The migration from Math.pow to the ** operator is consistent with the broader Biome formatting changes across the codebase.

backend/tests/wikibase-error-handler.test.ts (1)

1-13: LGTM! Import organization improvements.

The explicit bun:test import at the top and reordered imports align with Biome's formatting conventions. No functional changes to the test suite.

backend/tests/error-handler.test.ts (1)

2-2: LGTM! Import reordering.

The import reorganization is consistent with Biome's import sorting conventions.

backend/src/types/error-handler.ts (1)

14-192: LGTM! Improved static method calls.

Replacing this.createErrorWithData with ApiErrorHandler.createErrorWithData in static methods is more explicit and follows best practices. Since all methods are static, using the class name directly is clearer than using this.

frontend/src/shared/stores/__tests__/drag-drop.store.test.ts (1)

1-1: Consolidated bun:test import — LGTM

Top-level single import keeps globals explicit and plays nicely with Biome. Nothing else to do here.

frontend/src/features/wikibase-schema/composables/__tests__/useStatementConfig.test.ts (1)

1-1: Consolidated bun:test imports look good.

Top-level import is clear and consistent with Biome’s style.

backend/tests/services/lowercase-conversion.service.test.ts (1)

1-1: Import consolidation to bun:test looks good.

Consistent top-level import; matches the tooling migration.

frontend/src/features/wikibase-schema/composables/__tests__/useValidationErrors.test.ts (1)

1-1: LGTM on moving bun:test to the top.

No behavioral change; aligns with the project-wide Biome cleanup.

frontend/src/features/wikibase-schema/composables/__tests__/usePropertySelection.test.ts (1)

1-1: Import reordering looks correct.

Consistent with the migration; no functional changes.

backend/tests/services/replace-operation.alter-table.service.test.ts (1)

1-1: bun:test import move is good.

Matches the standardized test import pattern.

backend/tests/api/project/project.replace.test.ts (1)

1-2: Top-level import consolidation looks good.

No behavior change; consistent with the Biome migration.

backend/tests/services/trim-whitespace.service.test.ts (1)

1-1: LGTM: consolidated bun:test import.

frontend/src/features/wikibase-schema/composables/__tests__/useValidation.test.ts (1)

1-1: LGTM: bun:test import moved to top; consistent with Biome import ordering.

frontend/src/features/wikibase-schema/stores/__tests__/schema.store.test.ts (1)

1-1: LGTM: consolidated bun:test import at top.

backend/src/services/constraint-validation.service.ts (2)

440-444: LGTM: block-scoped case prevents fall-through and clarifies intent.


60-66: Verify constraint statement selection source.

Using property.statements[property.id] seems suspect; constraints typically live under a dedicated property (e.g., constraint property) rather than the entity’s own id. Confirm the shape returned by wikibaseService.getProperty and adjust the key accordingly.

I can wire a test that stubs wikibaseService.getProperty with realistic data and asserts parseConstraintsFromProperty extracts from the expected key.

backend/tests/constraint-validation.service.test.ts (1)

1-1: LGTM: bun:test import moved to top.

backend/tests/services/uppercase-conversion.service.test.ts (1)

1-1: LGTM: consolidated bun:test import.

frontend/src/features/wikibase-schema/composables/__tests__/useValueMapping.test.ts (1)

1-1: Consolidated bun:test import — good cleanup.

Single top-level import improves consistency; no behavior change.

frontend/src/features/wikibase-schema/composables/__tests__/useSchemaValidationUI.test.ts (1)

1-1: Consolidated bun:test import — looks good.

Removes duplication; improves clarity.

frontend/src/main.ts (1)

9-12: Import reordering + type-only Component — thumbs up.

Aligns with tree-shaking and clearer type/value separation; no runtime change.

frontend/src/features/wikibase-schema/stores/schema.store.ts (1)

12-12: Type-only import consolidation — OK.

Merging ItemId and StatementRank into one type import is fine.

frontend/src/features/wikibase-schema/stores/__tests__/validation-rules.store.test.ts (1)

1-1: Import reordering looks good.

Consistent placement of bun:test first across tests.

frontend/src/core/plugins/api.ts (1)

3-3: LGTM on import reordering.

Type-first grouping is fine and has no runtime impact.

frontend/src/features/wikibase-schema/components/SchemaSelector.vue (1)

29-29: LGTM on Number.isNaN usage.

Stricter NaN check is appropriate here.

Also applies to: 47-47

backend/tests/db.test.ts (1)

2-2: Import order change is fine.

Keeps test runner imports grouped first.

frontend/vite.config.ts (1)

13-13: LGTM! Improved approach for timestamp generation.

Date.now() is more direct and idiomatic than new Date().getTime() for obtaining the current timestamp in milliseconds. Both produce identical results.

backend/src/services/wikibase-clients.ts (1)

1-1: LGTM! Correct type-only import conversion.

All three imported identifiers (CSRFTokenResponse, InstanceId, OAuthCredentials) are used exclusively as TypeScript types throughout the file, never as runtime values. Converting to a type-only import is appropriate and can improve build performance.

frontend/src/features/wikibase-schema/composables/__tests__/useStatementDataTypeValidation.test.ts (1)

1-13: LGTM! Simplified test setup by inlining fixtures.

Replacing the beforeEach hook with a const declaration is appropriate since testProperties is only read in the tests and never mutated. This reduces per-test overhead and aligns with the broader PR pattern of consolidating test setup.

backend/src/plugins/database.ts (1)

2-2: LGTM! Correctly distinguishes type-only from value imports.

DuckDBConnection is only used as a type annotation, so marking it as a type-only import is correct. DuckDBInstance remains a value import because it's used at runtime (line 13: DuckDBInstance.create(dbPath)).

frontend/src/features/data-processing/composables/useColumnGeneration.ts (1)

1-1: LGTM! Correct type-only import conversion.

DuckDBColumnSchema is used exclusively as a type annotation for the schema parameter (line 13) and not as a runtime value. Converting to a type-only import is appropriate.

frontend/src/features/wikibase-schema/components/ValidationDisplay.vue (2)

63-69: LGTM! Improved immutability with const.

The intermediate variable is assigned once and never mutated, so using const instead of let is more appropriate and prevents accidental reassignment.


71-77: LGTM! Improved immutability with const.

Consistent with the errors computed property above, using const for the intermediate variable is more appropriate.

frontend/src/core/router/router.ts (1)

50-50: LGTM! Proper convention for unused parameters.

Renaming the unused from parameter to _from follows the convention of prefixing unused parameters with an underscore, which helps communicate intent and satisfies linter rules.

frontend/src/features/wikibase-schema/composables/__tests__/useStatementEditor.test.ts (2)

1-53: LGTM! Simplified test setup with inline fixtures.

The refactoring removes the beforeEach hook in favor of module-level const declarations, which is appropriate since these fixtures are read-only. This pattern reduces per-test overhead and aligns with the broader PR's test reorganization strategy.


214-214: LGTM! Type assertion for clarity.

The explicit type assertion ensures TypeScript correctly infers the type when passing the column to handleColumnDrop, which helps maintain type safety.

backend/src/api/project/index.ts (2)

7-7: LGTM! Type-only imports improve code clarity.

Converting to type-only imports (type Project, type DuckDBTablePragma, and import type { DuckDBResultReader }) is appropriate since these are only used in type positions. This optimization prevents unnecessary runtime imports and aligns with TypeScript best practices.

Also applies to: 20-21


411-411: LGTM! Explicit type annotation improves readability.

Adding the explicit type annotation DuckDBResultReader clarifies the variable's type and aligns with TypeScript best practices for the Biome migration.

backend/tests/api/project/project.get.test.ts (1)

1-1: LGTM! Import consolidation improves organization.

Consolidating bun:test imports at the top of the file follows standard conventions and improves readability. This aligns with the broader PR pattern of organizing test imports consistently across the codebase.

backend/tests/api/project/project.delete.test.ts (1)

1-1: LGTM! Import consolidation improves organization.

Consolidating bun:test imports at the top aligns with the broader PR pattern and improves test file organization.

frontend/src/features/wikibase-schema/composables/__tests__/useSchemaCompletenessIntegration.test.ts (1)

1-1: LGTM! Import consolidation improves organization.

Consolidating bun:test imports at the top follows the consistent pattern applied across both frontend and backend test files in this PR.

backend/tests/api/project/project.get-all.test.ts (1)

11-13: LGTM! Import organization improved.

The import reordering maintains functionality while improving code organization as part of the Biome migration.

backend/tests/api/_meta_projects.test.ts (1)

1-1: LGTM! Import consolidation improves organization.

Consolidating bun:test imports at the top aligns with the consistent pattern across all test files in this PR.

frontend/src/features/wikibase-schema/composables/__tests__/useSchemaCompletenessValidation.test.ts (1)

1-1: LGTM! Import consolidation improves organization.

Consolidating bun:test imports at the top maintains consistency with the broader PR pattern.

backend/tests/api/project/lowercase.test.ts (1)

1-2: LGTM! Import consolidation improves organization.

Adding top-level imports for bun:test and node:os, while removing duplicates later in the file, follows the consistent pattern applied across all test files in this PR.

frontend/src/features/wikibase-schema/composables/useSchemaApi.ts (1)

3-3: LGTM! Type-only import optimization.

Converting ApiErrors to a type-only import is appropriate since it's only used for type annotations throughout the file (lines 42, 66, 84, 105, 120). This improves bundle size and clarifies the compile-time-only usage.

frontend/src/features/wikibase-schema/composables/__tests__/useSchemaApi.test.ts (1)

1-1: LGTM! Test import consolidation.

Consolidating the bun:test import at the top follows the consistent pattern across the PR's test file updates and improves import organization.

backend/tests/api/project/uppercase.test.ts (1)

1-2: LGTM! Import consolidation.

Moving test framework and Node.js imports to the top aligns with the PR's import organization pattern across all test files.

backend/tests/api/project/project.import-csv.test.ts (1)

1-1: LGTM! Test import consolidation.

Consistent with the PR-wide pattern of consolidating test imports at the top of test files.

backend/tests/api/project/project.create.test.ts (1)

1-1: LGTM! Test import consolidation.

Aligns with the consistent import organization pattern applied across the test suite.

backend/tests/api/project/import-file.test.ts (1)

1-2: LGTM! Import consolidation.

Consolidating test and filesystem imports at the top follows the consistent pattern across all test files in this migration.

.biomeignore (1)

1-12: LGTM! Appropriate ignore patterns for Biome tooling.

The ignore patterns appropriately exclude build artifacts (dist/), dependencies (node_modules/, bun.lock), generated files (*.d.ts), temporary files (temp/, *.db, *.wal), and version control directories. These are standard exclusions that align with the migration to Biome.

backend/tests/api/project/project.wikibase.test.ts (1)

1-7: LGTM! Import organization.

Consolidating the bun:test import at the top and grouping wikibaseRoutes with related imports improves consistency and readability, aligning with the PR's import organization pattern.

backend/tests/api/project/import.test.ts (2)

1-1: LGTM! Import consolidation improves readability.

The consolidation of test utilities from bun:test into a single import statement at the top of the file is a clean improvement and aligns with the organize imports feature enabled in the new Biome configuration.


85-87: LGTM! Formatting change for better readability.

The multiline formatting of expect.stringContaining() improves readability without affecting test behavior.

backend/tests/api/project/project.import-file.test.ts (1)

1-2: LGTM! Consistent import consolidation.

The consolidation of bun:test imports and moving readdir to a top-level import statement improves code organization and aligns with the new Biome tooling configuration.

backend/package.json (1)

33-33: ESLint and Prettier successfully removed.

The removal of ESLint and Prettier dependencies aligns with the migration to Biome. Ensure the lint script (line 13) is also updated to reference Biome.

package.json (3)

9-12: LGTM! Scripts successfully migrated to Biome.

The format, lint, and check scripts have been correctly updated to use Biome commands. The addition of check:fix provides a convenient way to auto-fix issues.


24-24: Version lock on @tsconfig/bun is reasonable.

Removing the caret (^) from @tsconfig/bun locks it to version 1.0.9, which can help prevent unexpected breaking changes in TypeScript configuration. This is a sensible choice for build tooling stability.


33-33: LGTM! Biome dependency added.

The @biomejs/biome package has been added to replace ESLint and Prettier, completing the migration to unified tooling.

biome.json (5)

1-17: LGTM! Well-structured Biome configuration.

The base configuration is comprehensive:

  • VCS integration with git and .gitignore respect
  • File matching limited to TypeScript and Vue files
  • Formatter settings are consistent (2-space indent, 100 line width, LF endings)

19-38: LGTM! Sensible linter rule customizations.

The linter configuration uses the recommended preset with thoughtful overrides:

  • noUnusedVariables: "warn" instead of error is developer-friendly
  • useConst: "error" enforces immutability
  • noExplicitAny: "off" provides flexibility when needed
  • noForEach: "off" allows functional style
  • Vue domain set to "all" for comprehensive Vue linting

40-55: LGTM! JavaScript and JSON formatting aligned with common conventions.

The formatting preferences are well-chosen:

  • Single quotes and semicolons "asNeeded" reduce noise
  • Trailing commas improve git diffs
  • Multiline attribute position improves readability for JSX/Vue

56-63: LGTM! Organize imports explains the PR changes.

The organizeImports: "on" setting explains the import consolidations seen throughout the test files in this PR. This feature helps maintain consistent import ordering automatically.


64-78: LGTM! Vue-specific overrides are appropriate.

Disabling useNamingConvention and noUnusedVariables for Vue files makes sense because:

  • Vue components often use PascalCase/kebab-case mixing
  • Vue's compiler directives can make variables appear unused to linters

Comment on lines +2 to +3
import type { App as ElysiaApp } from '@backend/index'
import type { treaty } from '@elysiajs/eden'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Blocking: type-only import of treaty breaks typeof usage (TS error).

typeof treaty needs a value symbol, but import type erases the value at compile time. This will fail type-checking.

Fix by removing the type-only import and querying the module type instead:

-import type { treaty } from '@elysiajs/eden'
+// no direct import of `treaty` needed in type space

-export type ApiClient = ReturnType<typeof treaty<ElysiaApp>>
+export type ApiClient = ReturnType<(typeof import('@elysiajs/eden'))['treaty']<ElysiaApp>>

Alternative: switch to a value import for treaty (less ideal in a types module):

- import type { treaty } from '@elysiajs/eden'
+ import { treaty } from '@elysiajs/eden'

To check for other occurrences, run:

Also applies to: 18-18


🏁 Script executed:

#!/bin/bash
rg -nP --type=ts '\bimport\s+type\s*\{\s*treaty\s*\}\s*from\s*[\"\']@elysiajs/eden[\"\']' -C1
rg -nP --type=ts '\bReturnType<\s*typeof\s+treaty\s*<'

Length of output: 68



🏁 Script executed:

#!/bin/bash
# Read the file to see actual imports and usage
cat frontend/src/shared/types/index.ts

Length of output: 413



🏁 Script executed:

#!/bin/bash
# Search for ApiClient usage to understand scope of impact
rg -n 'ApiClient' frontend/src --type=ts

# Also check for tsconfig to understand TypeScript settings
cat tsconfig.json 2>/dev/null || cat frontend/tsconfig.json 2>/dev/null || echo "tsconfig.json not found in expected locations"

Length of output: 506



🏁 Script executed:

#!/bin/bash
# Find frontend tsconfig
find frontend -name "tsconfig*.json" -type f

# Check if there's a package.json to understand dependencies
cat frontend/package.json 2>/dev/null | grep -A 5 -B 5 "@elysiajs/eden" || echo "Could not find @elysiajs/eden in frontend package.json"

Length of output: 298



🏁 Script executed:

#!/bin/bash
# Check frontend tsconfig settings
cat frontend/tsconfig.json

Length of output: 491



🌐 Web query:

@elysiajs/eden treaty export type or value

💡 Result:

"treaty" from @elysiajs/eden is a runtime export (a function/value) you import and call (it also has TypeScript generics for typing). See the Eden docs showing import { treaty } from '@elysiajs/eden' and using treaty('localhost:3000'). [1][2]

Sources:
[1] ElysiaJS — Eden Treaty overview and examples.
[2] ElysiaJS — Eden Installation (usage showing import { treaty } from '@elysiajs/eden').


Blocking: type-only import of treaty breaks typeof usage (confirmed TS error).

The treaty from @elysiajs/eden is a runtime value, not a type. Using import type erases it from the value space, making typeof treaty fail at type-check time.

Affected locations:

  • frontend/src/shared/types/index.ts line 18
  • frontend/src/core/plugins/api.ts line 5

Fix by switching to a value import:

-import type { treaty } from '@elysiajs/eden'
+import { treaty } from '@elysiajs/eden'

Alternatively, use dynamic import if keeping the types-only module is preferred:

-import type { treaty } from '@elysiajs/eden'

-export type ApiClient = ReturnType<typeof treaty<ElysiaApp>>
+export type ApiClient = ReturnType<(typeof import('@elysiajs/eden'))['treaty']<ElysiaApp>>
📝 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.

Suggested change
import type { App as ElysiaApp } from '@backend/index'
import type { treaty } from '@elysiajs/eden'
import type { App as ElysiaApp } from '@backend/index'
import { treaty } from '@elysiajs/eden'
🤖 Prompt for AI Agents
In frontend/src/shared/types/index.ts (around lines 2–3 and 18) and
frontend/src/core/plugins/api.ts (around line 5), the import was declared as a
type-only import for `treaty` but `treaty` is a runtime value and `typeof
treaty` fails; change the import from a type-only import to a value import
(replace `import type { treaty }` with `import { treaty }`) in both places so
the value exists at runtime; if you must keep types-only semantics instead, load
the module dynamically where `typeof treaty` is used (e.g., await
import('@elysiajs/eden') and read .treaty) and adjust typing accordingly.

@DaxServer DaxServer merged commit 7427323 into main Oct 17, 2025
6 checks passed
@DaxServer DaxServer deleted the biome branch October 17, 2025 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants