chore: re-organize frontend folder structure #109
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis change updates import paths throughout the frontend codebase to align with a new directory structure. All affected files—including type declarations, component auto-imports, router configuration, feature composables, stores, and tests—now reference their dependencies under newly organized Changes
Sequence Diagram(s)No sequence diagram is generated, as the changes are limited to import path updates and do not affect control flow or feature logic. Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (8)
frontend/src/shared/composables/__tests__/useColumnConversion.test.ts (1)
3-3: Consider relocatingProjectColumnto a shared types module.Importing a type from inside another composable (
useColumnGeneration) couples the test (and any other consumer) to that implementation file.
IfProjectColumnis reused across features, exposing it under@frontend/shared/typeswould avoid potential circular-dependency issues when the composable itself evolves.frontend/src/shared/stores/__tests__/validation-rules.store.test.ts (1)
4-4: DecoupleValidationRuleConfigfrom the store implementation.Similar to the previous note, importing the type from the store file forces any consumer to depend on store internals.
MovingValidationRuleConfigto@frontend/shared/types/wikibase-schema(or a dedicatedmodelsbarrel) would make the public API cleaner.frontend/src/features/wikibase-schema/composables/useSchemaCompletenessValidation.ts (1)
2-3: Alias paths look good – ensure tsconfigpathsis in syncThe new feature-scoped aliases compile only if
tsconfig.json(andvite.config.ts/bunfig.tomlif applicable) maps@frontend/features/*correctly.
Please double-check; otherwise Vue TS Server will fall back to relative resolution and break IntelliSense/builds.frontend/src/main.ts (1)
11-18: Path changes fine, but consider a barrel export to shorten deep imports
@frontend/core/router/routerand@frontend/core/plugins/apiare verbose.
Addingindex.tsre-exports (barrels) would let consumers do:import router from '@frontend/core/router' import { ApiPlugin } from '@frontend/core/plugins'This keeps call-sites clean and avoids churn if filenames move again.
frontend/src/features/data-processing/stores/drag-drop.store.ts (1)
3-6: Alias switch is fine; opportunistic nit – drop non-feature import commentSince the file now lives under
features/data-processing, consider dropping the internal comment “Use the shared compatibility mapping” (Line 39) – it predates the move and is slightly redundant.No functional issues with the change itself.
frontend/src/features/wikibase-schema/composables/useStatementValidationDisplay.ts (1)
1-2: Consider local relative import for same-feature composable
useStatementDataTypeValidationlives in the same folder. A relative import ('./useStatementDataTypeValidation') avoids an unnecessary alias hop and reduces risk of circular-alias resolution issues.-import { useStatementDataTypeValidation } from '@frontend/features/wikibase-schema/composables/useStatementDataTypeValidation' +import { useStatementDataTypeValidation } from './useStatementDataTypeValidation'frontend/src/features/wikibase-schema/composables/useStatementEditor.ts (1)
8-9: New cross-feature dependency – confirm intended layering
wikibase-schemanow depends onfeatures/data-processing.
If you aim for feature isolation, consider movinguseDataTypeCompatibilitytosharedinstead.frontend/src/core/router/router.ts (1)
7-33: Consider adding chunk-names for improved bundle introspection.
The dynamic imports work, but you can make debugging and bundle analysis easier by naming the chunks:- component: () => import('@frontend/core/layouts/DefaultLayout.vue'), + component: () => + import( + /* webpackChunkName: "layout-default" */ + '@frontend/core/layouts/DefaultLayout.vue' + ),Same for the three feature pages below.
| ReferenceSchemaMapping, | ||
| } from '@frontend/types/wikibase-schema' | ||
| } from '@frontend/shared/types/wikibase-schema' | ||
| import type { UUID } from 'crypto' |
There was a problem hiding this comment.
import type { UUID } from 'crypto' is invalid and will break builds
Node/Bun’s crypto module exports the randomUUID() function but does not export a UUID type alias.
TypeScript will raise “Module … has no exported member ‘UUID’”.
Proposed quick fix:
-import type { UUID } from 'crypto'
+// Define a simple UUID alias locally (or import from a dedicated util)
+type UUID = stringAll UUID usages below then remain valid.
📝 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 { UUID } from 'crypto' | |
| // Define a simple UUID alias locally (or import from a dedicated util) | |
| type UUID = string |
🤖 Prompt for AI Agents
In frontend/src/features/wikibase-schema/composables/useSchemaBuilder.ts at line
14, the import statement `import type { UUID } from 'crypto'` is invalid because
the 'crypto' module does not export a `UUID` type. Remove this import entirely
and instead define the `UUID` type locally as a string alias or use an
appropriate existing type alias for UUIDs. This will keep all `UUID` usages
valid without causing build errors.
| import { useDragDropStore } from '@frontend/features/data-processing/stores/drag-drop.store' | ||
| import { useSchemaStore } from '@frontend/features/wikibase-schema/stores/schema.store' | ||
| import type { ColumnInfo } from '@frontend/shared/types/wikibase-schema' | ||
| import { useDragDropHandlers } from '@frontend/shared/composables/useDragDropHandlers' | ||
| import { useValidationCore } from '@frontend/features/wikibase-schema/composables/useValidationCore' | ||
| import { useDropZoneStyling } from '@frontend/shared/composables/useDropZoneStyling' |
There was a problem hiding this comment.
WikibaseDataType is referenced but not imported – compilation will fail
acceptedTypes is typed as WikibaseDataType[], however the symbol is never imported.
Add it alongside ColumnInfo:
-import type { ColumnInfo } from '@frontend/shared/types/wikibase-schema'
+import type { ColumnInfo, WikibaseDataType } from '@frontend/shared/types/wikibase-schema'Also applies to: 26-27
🤖 Prompt for AI Agents
In frontend/src/features/wikibase-schema/composables/useSchemaDropZone.ts around
lines 2 to 7 and also lines 26 to 27, the type WikibaseDataType is used but not
imported, causing compilation errors. Fix this by importing WikibaseDataType
from the appropriate module alongside ColumnInfo at the top of the file. Ensure
the import statement correctly references the source of WikibaseDataType to
resolve the missing symbol issue.
1 participant
No description provided.