-
Notifications
You must be signed in to change notification settings - Fork 0
feat: migrate to biomejs #178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughComprehensive 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
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
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this 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 whentype === 'filepath', thepathproperty 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...withoutawaitor returning the Promise. The test can finish before the assertion runs, causing false positives. Useawait expect(...)...(orreturn 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 missingasynckeywords andawaiton Promise matchers in tests.The review comment is correct. Six test functions use
.rejectsor.resolvesmatchers 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/.rejectscan 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<...>needsRefimported 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 onstatements1can throw; add guards and init arrays.Several places assume presence of
statements1[statementId],qualifiers, orreferences. 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) returnThis 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 leavesstatementsstale.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 invalidUUIDtype import from 'crypto'—this will cause a compilation error.The Node.js
cryptomodule does not export aUUIDtype, onlyrandomUUID()which returns astring. The import at line 15 is invalid and will fail to compile. SinceUUIDis used throughout the file and in shared types, replace the broken import with a local type alias:-import type { UUID } from 'crypto' +type UUID = stringAlternatively, 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:toLocaleDateStringignores time options; usetoLocaleString.Time fields (
hour,minute) are ignored bytoLocaleDateString. 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
timeZoneortimeStyle: '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
lintscript still referenceseslint, but ESLint was removed fromdevDependencies(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 usingpath.joinfor 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 importImporting
WikibaseDataTypefrom@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 dataTypeUse the source type instead of
stringto prevent drift ifColumnInfo['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: Usepath.joinfor 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
getPropertyConstraintsitself, so the “cache” path isn’t verified. Consider mockingwikibaseService.getPropertyinstead 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 (statementsandstatements1).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 honorApiPluginoptions.-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
⛔ Files ignored due to path filters (1)
bun.lockis 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:testimports and proper use of thetypekeyword forColumnInfoare 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:testimports 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
extnameto 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:testimport at the top (line 1) follows best practices, and the type-only import on line 3 is already using the properimport typekeyword. 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
typekeyword 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:testimports 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:testimports 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:testimport 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:testandnode:osimports 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
basenameand 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
basenameimproves 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)to2 ** attemptis 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.powto 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:testimport 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.createErrorWithDatawithApiErrorHandler.createErrorWithDatain static methods is more explicit and follows best practices. Since all methods are static, using the class name directly is clearer than usingthis.frontend/src/shared/stores/__tests__/drag-drop.store.test.ts (1)
1-1: Consolidated bun:test import — LGTMTop-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 bywikibaseService.getPropertyand adjust the key accordingly.I can wire a test that stubs
wikibaseService.getPropertywith realistic data and assertsparseConstraintsFromPropertyextracts 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:testfirst 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 onNumber.isNaNusage.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 thannew 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
beforeEachhook with a const declaration is appropriate sincetestPropertiesis 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.
DuckDBConnectionis only used as a type annotation, so marking it as a type-only import is correct.DuckDBInstanceremains 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.
DuckDBColumnSchemais used exclusively as a type annotation for theschemaparameter (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
constinstead ofletis more appropriate and prevents accidental reassignment.
71-77: LGTM! Improved immutability with const.Consistent with the errors computed property above, using
constfor the intermediate variable is more appropriate.frontend/src/core/router/router.ts (1)
50-50: LGTM! Proper convention for unused parameters.Renaming the unused
fromparameter to_fromfollows 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
beforeEachhook 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, andimport 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
DuckDBResultReaderclarifies 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
ApiErrorsto 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:testimport 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:testimport at the top and groupingwikibaseRouteswith 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:testinto 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:testimports and movingreaddirto 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
lintscript (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:fixprovides a convenient way to auto-fix issues.
24-24: Version lock on @tsconfig/bun is reasonable.Removing the caret (
^) from@tsconfig/bunlocks it to version1.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/biomepackage 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
.gitignorerespect- 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-friendlyuseConst: "error"enforces immutabilitynoExplicitAny: "off"provides flexibility when needednoForEach: "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
useNamingConventionandnoUnusedVariablesfor Vue files makes sense because:
- Vue components often use PascalCase/kebab-case mixing
- Vue's compiler directives can make variables appear unused to linters
| import type { App as ElysiaApp } from '@backend/index' | ||
| import type { treaty } from '@elysiajs/eden' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 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.tsLength 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.jsonLength 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.
| 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.
No description provided.