refactor: Implement scoped exports to replace hoisted / peer providers#414
Conversation
+ Makes it more clear how references work
ENG-517 Implement scoped exports to replace hoisted / peer providers
Introduce a more intuitive and flexible scoping system for provider exports in the Sync Engine, replacing the current hoisted/peer provider mechanism with explicit scopes that define the visibility and accessibility of providers. |
🦋 Changeset detectedLatest commit: c2e70d3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThe changes introduce a comprehensive refactoring of dependency management and provider scoping across multiple packages. The primary focus is on implementing a new concept of scopes for provider dependency resolution, which replaces existing methods of hoisting, peer, and parent resolution. This modification enhances the granularity of how providers are resolved and exported within the system. Key changes include:
Changes
Sequence DiagramsequenceDiagram
participant Generator
participant ScopesModule
participant DependencyResolver
Generator->>ScopesModule: Import projectScope/featureScope
Generator->>Generator: Modify export mechanism
Generator->>DependencyResolver: Resolve dependencies with new scoping
Note over Generator,DependencyResolver: Providers now exported with explicit scopes
Note over Generator,ScopesModule: Granular control over dependency resolution
This diagram illustrates the new approach to provider exports and dependency resolution, highlighting the introduction of explicit scoping mechanisms. Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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: 8
🔭 Outside diff range comments (1)
packages/fastify-generators/src/generators/prisma/prisma-crud-delete/index.ts (1)
Line range hint
143-147: Remove redundant empty provider objectSince
PrismaDeleteMethodProviderhas been removed as part of the provider scoping refactor, returning an empty object forprismaDeleteMethodis unnecessary and should be removed.return { - getProviders: () => ({ - prismaDeleteMethod: {}, - }), + getProviders: () => ({}), };
🧹 Nitpick comments (18)
packages/fastify-generators/src/generators/prisma/prisma-crud-delete/index.ts (1)
Line range hint
1-150: Consider documenting the new provider scoping patternThe removal of the provider type and its export aligns well with the refactoring goals. However, to maintain consistency across the codebase and help other developers understand the new pattern, consider:
- Adding a comment explaining why this generator no longer needs to expose providers
- Updating relevant documentation to reflect the new scoping approach
- Creating examples of how consumers should now interact with this generator
This will help ensure smooth adoption of the new architecture.
packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (1)
58-60: LGTM: Proper implementation of scoped exports patternThe modification to use
yogaPluginSetupProvider.export(projectScope)aligns with the new dependency management approach. This scoped export pattern provides better control over provider visibility and dependency resolution.This pattern offers several benefits:
- Clearer dependency boundaries
- More predictable provider resolution
- Better isolation between different parts of the application
packages/fastify-generators/src/generators/prisma/prisma-field/index.ts (1)
Line range hint
21-44: Clean up TODO and enhance error handling in schema validationThe schema validation has a TODO comment and could benefit from more robust error handling in the
superRefinecallback.Consider this improvement:
.superRefine((obj, ctx) => { - // TODO: Clean up const schema = prismaScalarFieldTypes[obj.type].optionsSchema; if (schema && obj.options) { const parseResult = schema.safeParse(obj.options); if (!parseResult.success) { - ctx.addIssue(parseResult.error.errors[0]); + // Add all validation errors with proper paths + parseResult.error.errors.forEach(error => { + ctx.addIssue({ + ...error, + path: ['options', ...(error.path || [])], + }); + }); } } return obj; });packages/sync/src/core/engine/dependency-map.ts (1)
22-24: Consider using a more deterministic method for generating provider IDsUsing
JSON.stringifyinmakeProviderIdto generate provider IDs may lead to inconsistent IDs if elements change order or if values are undefined. Consider using a more deterministic method, such as concatenating strings with a delimiter, to ensure consistent and unique provider IDs.packages/fastify-generators/src/generators/pothos/providers/scopes.ts (1)
3-6: Consider enhancing the scope descriptionThe scope implementation looks good and follows the hierarchical naming pattern. However, consider making the description more descriptive to better convey its purpose.
export const pothosFieldScope = createProviderExportScope( 'fastify/pothos-field', - 'Pothos field', + 'Scope for Pothos GraphQL field providers', );packages/fastify-generators/src/generators/vitest/fastify-vitest/index.ts (1)
3-3: LGTM! Consider documenting scope usage.The change to use
projectScopeforfastifyVitestis appropriate as test configurations are typically project-wide. The import and export modifications are consistent with the new architecture.Consider adding a comment explaining why
projectScopewas chosen for this provider:exports: { + // Using projectScope as test configurations are project-wide fastifyVitest: fastifyVitestProvider.export(projectScope), },Also applies to: 30-30
packages/react-generators/src/generators/admin/admin-crud-section/index.ts (1)
18-21: Well-structured custom scope implementation!Good choice creating a dedicated scope for admin CRUD sections instead of using
projectScope. This provides better isolation and clearer boundaries for admin-specific functionality.This pattern of creating dedicated scopes for feature-specific providers is a good practice that you might want to apply to other similar features in the codebase. It helps with:
- Better dependency tracking
- Clearer boundaries between features
- More precise control over provider visibility
Also applies to: 48-48, 50-50
packages/react-generators/src/generators/admin/admin-home/index.ts (1)
36-36: Consider defining explicit provider typeWhile the export modification is correct, the
AdminHomeProvidertype is currently defined asunknown. Consider defining a more specific interface to improve type safety.export interface AdminHomeProvider { // Add relevant provider methods/properties here }packages/fastify-generators/src/generators/email/fastify-sendgrid/index.ts (1)
32-32: Consider enhancing provider type and configuration handlingWhile the export modification is correct, consider these improvements:
- Define a specific interface for
FastifySendgridProviderinstead ofunknown- Consider adding validation for the Sendgrid API key format
export interface FastifySendgridProvider { // Add relevant provider methods/properties getSendgridConfig(): { apiKey: string; // Add other config properties }; }packages/fastify-generators/src/generators/auth/user-session-types/index.ts (1)
Line range hint
1-1: Overall Implementation ReviewThe implementation of scoped exports across these files is consistent and well-structured. Special attention has been given to security-sensitive components (password hasher, session types) to ensure proper isolation. The refactoring improves dependency management by replacing hoisted/peer providers with scoped exports.
Consider documenting the new scoped exports pattern in the project's technical documentation to help other developers understand:
- The purpose and benefits of using scoped exports
- When to use project scope vs. other scopes
- Best practices for implementing scoped exports in new generators
packages/sync/src/core/engine/engine.ts (1)
34-54: Consider enhancing error handling in loadProjectThe
loadProjectmethod could benefit from more robust error handling for scenarios like:
- Missing project directory
- Invalid descriptor file
- Failed generator loading
Consider wrapping critical operations in try-catch blocks:
async loadProject( directory: string, logger: Logger = console, ): Promise<GeneratorEntry> { + try { const projectPath = path.join(directory, 'baseplate'); const rootDescriptor = await loadDescriptorFromFile( path.join(projectPath, 'root'), ); const generators = await loadGeneratorsForProject( this.builtInGeneratorModulePaths, directory, ); const rootGeneratorEntry = await buildGeneratorEntry( rootDescriptor, 'root', { baseDirectory: projectPath, generatorMap: generators, logger }, ); return rootGeneratorEntry; + } catch (error) { + logger.error('Failed to load project:', error); + throw new Error(`Failed to load project: ${error.message}`); + } }packages/react-generators/src/generators/core/react-app/index.ts (1)
Line range hint
1-100: Consider documenting the new scoped exports pattern.The implementation of scoped exports appears to be a significant architectural change affecting multiple generators. Consider:
- Adding documentation about:
- The purpose and benefits of scoped exports
- How it differs from the previous hoisted/peer providers
- Best practices for implementing scoped exports in new generators
- Adding tests to verify the behavior of scoped exports with different provider types (regular, readOnly, etc.)
This will help maintain consistency as the pattern is adopted across more generators.
packages/fastify-generators/src/generators/pothos/pothos-prisma-primary-key/index.ts (1)
3-3: LGTM! Consider extracting the scope key to a constant.The implementation correctly uses scoped exports with model-specific scope keys. The template literal
prisma-primary-key-type:${modelName}effectively namespaces the type output.Consider extracting the scope key prefix to improve maintainability:
+const SCOPE_KEY_PREFIX = 'prisma-primary-key-type'; + exports: { pothosTypeOutput: pothosTypeOutputProvider.export( projectScope, - `prisma-primary-key-type:${modelName}`, + `${SCOPE_KEY_PREFIX}:${modelName}`, ), },Also applies to: 38-41
packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (1)
89-94: Document the dual-export pattern.The implementation correctly exports to both children and project scope using method chaining. Consider adding a comment explaining why this dual-export pattern is necessary.
exports: { prismaCrudService: prismaCrudServiceProvider - // export to children and project under model name + // This service needs to be available to: + // 1. Child generators (through .export()) + // 2. Project scope (through .andExport()) for external consumption .export() .andExport(projectScope, modelName), },packages/react-generators/src/generators/apollo/react-apollo/index.ts (1)
104-105: LGTM: Implementation of scoped exportsThe exports have been properly updated to use
projectScope, implementing the new provider dependency resolution pattern. This change enhances dependency management by providing better scoping control.This architectural change improves dependency resolution by:
- Replacing hoisting/peer resolution with explicit scoping
- Providing better control over provider visibility
- Enabling more predictable dependency management
packages/fastify-generators/src/generators/prisma/embedded-relation-transformer/index.ts (1)
195-199: LGTM: Updated dependency resolutionThe dependency resolution has been updated to use
optionalReferencewithforeignModelName, aligning with the new scoped provider pattern.This change improves the architecture by:
- Making the dependency relationship more explicit
- Leveraging the new scoped provider resolution system
- Maintaining optional dependency handling
.changeset/quiet-swans-leave.md (1)
1-10: LGTM: Comprehensive version managementThe changeset correctly:
- Uses minor version bump for @halfdomelabs/sync due to the new feature
- Uses patch versions for affected packages
- Clearly describes the architectural change
The version management strategy properly reflects the architectural impact:
- Minor bump for new functionality in the core package
- Patch bumps for implementation changes in dependent packages
packages/react-generators/src/generators/auth/auth-login-page/index.ts (1)
Line range hint
31-47: Architecture improvement: Better provider scopingThe refactoring improves the provider resolution system by:
- Making dependencies more explicit through scoped exports
- Providing better control over provider visibility
- Following a consistent pattern across generators
This aligns well with the PR's objective of replacing hoisted/peer providers with scoped exports.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (132)
.changeset/quiet-swans-leave.md(1 hunks).changeset/soft-bottles-poke.md(1 hunks)packages/core-generators/src/generators/node/eslint/index.ts(2 hunks)packages/core-generators/src/generators/node/node-git-ignore/index.ts(2 hunks)packages/core-generators/src/generators/node/node/index.ts(4 hunks)packages/core-generators/src/generators/node/prettier/index.ts(2 hunks)packages/core-generators/src/generators/node/ts-utils/index.ts(2 hunks)packages/core-generators/src/generators/node/typescript/index.ts(3 hunks)packages/core-generators/src/generators/node/vitest/index.ts(2 hunks)packages/core-generators/src/providers/index.ts(1 hunks)packages/core-generators/src/providers/scopes.ts(1 hunks)packages/fastify-generators/src/generators/auth/auth-context/index.ts(2 hunks)packages/fastify-generators/src/generators/auth/auth-plugin/index.ts(0 hunks)packages/fastify-generators/src/generators/auth/auth-roles/index.ts(2 hunks)packages/fastify-generators/src/generators/auth/auth/index.ts(3 hunks)packages/fastify-generators/src/generators/auth/password-hasher-service/index.ts(2 hunks)packages/fastify-generators/src/generators/auth/user-session-types/index.ts(2 hunks)packages/fastify-generators/src/generators/auth0/auth0-module/index.ts(2 hunks)packages/fastify-generators/src/generators/bull/bullmq/index.ts(2 hunks)packages/fastify-generators/src/generators/bull/fastify-bull-board/index.ts(3 hunks)packages/fastify-generators/src/generators/core/app-module/index.ts(2 hunks)packages/fastify-generators/src/generators/core/config-service/index.ts(2 hunks)packages/fastify-generators/src/generators/core/error-handler-service/index.ts(3 hunks)packages/fastify-generators/src/generators/core/fastify-health-check/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify-redis/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify-scripts/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify-sentry/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify-server/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify/index.ts(3 hunks)packages/fastify-generators/src/generators/core/logger-service/index.ts(2 hunks)packages/fastify-generators/src/generators/core/request-context/index.ts(2 hunks)packages/fastify-generators/src/generators/core/request-service-context/index.ts(3 hunks)packages/fastify-generators/src/generators/core/root-module/index.ts(4 hunks)packages/fastify-generators/src/generators/core/service-context/index.ts(3 hunks)packages/fastify-generators/src/generators/core/service-file/index.ts(4 hunks)packages/fastify-generators/src/generators/email/fastify-postmark/index.ts(2 hunks)packages/fastify-generators/src/generators/email/fastify-sendgrid/index.ts(2 hunks)packages/fastify-generators/src/generators/pothos/index.ts(1 hunks)packages/fastify-generators/src/generators/pothos/pothos-auth/index.ts(2 hunks)packages/fastify-generators/src/generators/pothos/pothos-enums-file/index.ts(1 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-crud-file/index.ts(0 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-crud-mutation/index.ts(3 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-get-query/index.ts(3 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-list-query/index.ts(3 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-object/index.ts(4 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma-primary-key/index.ts(2 hunks)packages/fastify-generators/src/generators/pothos/pothos-prisma/index.ts(2 hunks)packages/fastify-generators/src/generators/pothos/pothos-types-file/index.ts(1 hunks)packages/fastify-generators/src/generators/pothos/pothos/index.ts(4 hunks)packages/fastify-generators/src/generators/pothos/providers/index.ts(1 hunks)packages/fastify-generators/src/generators/pothos/providers/scopes.ts(1 hunks)packages/fastify-generators/src/generators/prisma/embedded-relation-transformer/index.ts(2 hunks)packages/fastify-generators/src/generators/prisma/prisma-crud-delete/index.ts(1 hunks)packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts(3 hunks)packages/fastify-generators/src/generators/prisma/prisma-enum/index.ts(1 hunks)packages/fastify-generators/src/generators/prisma/prisma-field/index.ts(1 hunks)packages/fastify-generators/src/generators/prisma/prisma-model/index.ts(3 hunks)packages/fastify-generators/src/generators/prisma/prisma-relation-field/index.ts(2 hunks)packages/fastify-generators/src/generators/prisma/prisma-utils/index.ts(2 hunks)packages/fastify-generators/src/generators/prisma/prisma/index.ts(3 hunks)packages/fastify-generators/src/generators/stripe/fastify-stripe/index.ts(2 hunks)packages/fastify-generators/src/generators/vitest/fastify-vitest/index.ts(2 hunks)packages/fastify-generators/src/generators/vitest/prisma-vitest/index.ts(2 hunks)packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts(3 hunks)packages/project-builder-lib/src/compiler/app-compiler-spec.ts(1 hunks)packages/project-builder-lib/src/parser/index.ts(0 hunks)packages/project-builder-lib/src/parser/plugins/auth.ts(0 hunks)packages/project-builder-lib/src/parser/plugins/auth0.ts(0 hunks)packages/project-builder-lib/src/parser/types.ts(0 hunks)packages/project-builder-server/package.json(1 hunks)packages/project-builder-server/src/compiler/admin/crud/index.ts(1 hunks)packages/project-builder-server/src/compiler/admin/crud/inputs.ts(3 hunks)packages/project-builder-server/src/compiler/admin/index.ts(0 hunks)packages/project-builder-server/src/compiler/admin/sections.ts(1 hunks)packages/project-builder-server/src/compiler/backend/fastify.ts(0 hunks)packages/project-builder-server/src/compiler/backend/feature.ts(0 hunks)packages/project-builder-server/src/compiler/backend/graphql.ts(3 hunks)packages/project-builder-server/src/compiler/backend/index.ts(1 hunks)packages/project-builder-server/src/compiler/backend/models.ts(1 hunks)packages/project-builder-server/src/compiler/backend/services.ts(2 hunks)packages/project-builder-server/src/compiler/lib/web-auth.ts(0 hunks)packages/project-builder-server/src/compiler/web/index.ts(0 hunks)packages/react-generators/src/generators/admin/admin-bull-board/index.ts(2 hunks)packages/react-generators/src/generators/admin/admin-components/index.ts(2 hunks)packages/react-generators/src/generators/admin/admin-crud-column/index.ts(1 hunks)packages/react-generators/src/generators/admin/admin-crud-edit/index.ts(1 hunks)packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts(4 hunks)packages/react-generators/src/generators/admin/admin-crud-embedded-input/index.ts(1 hunks)packages/react-generators/src/generators/admin/admin-crud-foreign-display/index.ts(1 hunks)packages/react-generators/src/generators/admin/admin-crud-list/index.ts(1 hunks)packages/react-generators/src/generators/admin/admin-crud-queries/index.ts(2 hunks)packages/react-generators/src/generators/admin/admin-crud-section/index.ts(3 hunks)packages/react-generators/src/generators/admin/admin-home/index.ts(2 hunks)packages/react-generators/src/generators/admin/admin-layout/index.ts(2 hunks)packages/react-generators/src/generators/apollo/apollo-error/index.ts(2 hunks)packages/react-generators/src/generators/apollo/react-apollo/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-apollo/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-components/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-hooks/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-identify/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-layout/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-login-page/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-pages/index.ts(2 hunks)packages/react-generators/src/generators/auth/auth-service/index.ts(2 hunks)packages/react-generators/src/generators/auth0/auth0-apollo/index.ts(3 hunks)packages/react-generators/src/generators/auth0/auth0-components/index.ts(2 hunks)packages/react-generators/src/generators/auth0/auth0-hooks/index.ts(2 hunks)packages/react-generators/src/generators/auth0/react-auth0/index.ts(2 hunks)packages/react-generators/src/generators/core/react-app/index.ts(2 hunks)packages/react-generators/src/generators/core/react-components/index.ts(2 hunks)packages/react-generators/src/generators/core/react-config/index.ts(2 hunks)packages/react-generators/src/generators/core/react-datadog/index.ts(2 hunks)packages/react-generators/src/generators/core/react-error-boundary/index.ts(2 hunks)packages/react-generators/src/generators/core/react-error/index.ts(2 hunks)packages/react-generators/src/generators/core/react-logger/index.ts(2 hunks)packages/react-generators/src/generators/core/react-not-found-handler/index.ts(2 hunks)packages/react-generators/src/generators/core/react-proxy/index.ts(2 hunks)packages/react-generators/src/generators/core/react-router/index.ts(2 hunks)packages/react-generators/src/generators/core/react-routes/index.ts(1 hunks)packages/react-generators/src/generators/core/react-sentry/index.ts(3 hunks)packages/react-generators/src/generators/core/react-tailwind/index.ts(2 hunks)packages/react-generators/src/generators/core/react-utils/index.ts(2 hunks)packages/react-generators/src/generators/core/react/index.ts(2 hunks)packages/react-generators/src/providers/linkable.ts(0 hunks)packages/sync/package.json(1 hunks)packages/sync/src/core/descriptor.ts(0 hunks)packages/sync/src/core/engine/dependency-map.ts(4 hunks)packages/sync/src/core/engine/dependency-map.unit.test.ts(1 hunks)packages/sync/src/core/engine/dependency-sort.unit.test.ts(3 hunks)packages/sync/src/core/engine/engine.ts(1 hunks)packages/sync/src/core/engine/generator-builder.ts(4 hunks)packages/sync/src/core/engine/generator-runner.ts(2 hunks)
⛔ Files not processed due to max files limit (24)
- packages/sync/src/core/engine/generator-runner.unit.test.ts
- packages/sync/src/core/engine/index.ts
- packages/sync/src/core/engine/tests/factories.test-helper.ts
- packages/sync/src/core/engine/utils.ts
- packages/sync/src/core/generator.ts
- packages/sync/src/core/provider.ts
- packages/sync/src/core/provider.unit.test.ts
- packages/sync/src/utils/create-generator-with-children.ts
- packages/sync/src/utils/create-generator-with-tasks.ts
- packages/sync/src/utils/validation.ts
- plugins/baseplate-plugin-storage/src/generators/fastify/prisma-file-transformer/index.ts
- plugins/baseplate-plugin-storage/src/generators/fastify/storage-module/index.ts
- plugins/baseplate-plugin-storage/src/generators/react/upload-components/index.ts
- plugins/baseplate-plugin-storage/src/storage/core/node.ts
- tests/simple/packages/backend/.gitignore
- tests/simple/packages/backend/baseplate/.clean/.gitignore
- tests/simple/packages/backend/baseplate/.clean/package.json
- tests/simple/packages/backend/baseplate/root.json
- tests/simple/packages/backend/package.json
- tests/simple/packages/web/.gitignore
- tests/simple/packages/web/baseplate/.clean/.gitignore
- tests/simple/packages/web/baseplate/.clean/vite.config.ts
- tests/simple/packages/web/baseplate/root.json
- tests/simple/packages/web/vite.config.ts
💤 Files with no reviewable changes (13)
- packages/project-builder-lib/src/parser/plugins/auth0.ts
- packages/project-builder-server/src/compiler/lib/web-auth.ts
- packages/project-builder-server/src/compiler/backend/feature.ts
- packages/fastify-generators/src/generators/auth/auth-plugin/index.ts
- packages/project-builder-lib/src/parser/types.ts
- packages/project-builder-server/src/compiler/backend/fastify.ts
- packages/project-builder-lib/src/parser/plugins/auth.ts
- packages/react-generators/src/providers/linkable.ts
- packages/fastify-generators/src/generators/pothos/pothos-prisma-crud-file/index.ts
- packages/project-builder-lib/src/parser/index.ts
- packages/project-builder-server/src/compiler/web/index.ts
- packages/project-builder-server/src/compiler/admin/index.ts
- packages/sync/src/core/descriptor.ts
✅ Files skipped from review due to trivial changes (1)
- packages/fastify-generators/src/generators/pothos/providers/index.ts
🔇 Additional comments (170)
packages/fastify-generators/src/generators/prisma/prisma-crud-delete/index.ts (1)
7-7: LGTM: Import aligned with new architectureThe change to import
createGeneratorWithChildrenaligns with the PR's objective of implementing scoped exports.packages/project-builder-server/src/compiler/admin/crud/index.ts (1)
33-33: LGTM! Verify downstream compatibility.The addition of form ID to the shared data structure looks correct and aligns with the refactoring goals. This change appears to support more granular identification of forms, which could be important for the new scoped export system.
Let's verify that downstream consumers are ready for this change:
✅ Verification successful
✓ Form ID usage verified and consistent
The addition of
form.idto shared data aligns with existing patterns in the codebase, where form IDs are already utilized for form identification. This change maintains consistency with the admin CRUD system's architecture.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for consumers of the compiled admin CRUD form output # to ensure they handle the new id field appropriately # Look for potential consumers in React components ast-grep --pattern 'const $_ = props.$_' packages/project-builder-client/src/components/admin/**/*.tsx # Look for direct references to form properties rg -A 3 'form\.' packages/project-builder-client/src/components/admin/**/*.tsxLength of output: 400
Script:
#!/bin/bash # First, let's find relevant files and patterns # Find admin-related TypeScript/JavaScript files fd -e ts -e tsx -e js -e jsx . | grep -i 'admin' # Search for form-related imports and usages rg -l "import.*['\"].*admin.*form" # Look for CRUD-related code patterns rg -l "AdminCrud" # Search for form ID usage patterns rg "form\.id"Length of output: 10317
packages/react-generators/src/generators/apollo/apollo-error/index.ts (2)
5-5: LGTM! Import addition aligns with scoped exports refactoringThe addition of
projectScopeimport is consistent with the PR's objective to implement scoped exports.
30-30: LGTM! Verify consistent scoping pattern across related generatorsThe modification to use
apolloErrorProvider.export(projectScope)aligns with the PR's objective of implementing scoped exports.Let's verify this pattern is consistently applied across related Apollo generators:
✅ Verification successful
✅ Verified: Consistent scoping pattern across Apollo generators
The
apolloErrorProvider.export(projectScope)implementation follows the same pattern used in other Apollo generators, including react-apollo's providers.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other Apollo generators to ensure consistent scoping pattern ast-grep --pattern 'apolloErrorProvider.export($_)' rg -A 1 'apolloErrorProvider' packages/react-generators/src/generators/apollo/Length of output: 705
Script:
#!/bin/bash # Find all Apollo-related generators fd -t f "index.ts" packages/react-generators/src/generators/apollo/ # Check export patterns in Apollo generators rg -A 2 "export const.*Provider" packages/react-generators/src/generators/apollo/Length of output: 1527
Script:
#!/bin/bash # Check how providers are exported in generator configurations rg -A 1 "Provider\.export\(" packages/react-generators/src/generators/apollo/Length of output: 641
packages/react-generators/src/generators/admin/admin-crud-queries/index.ts (2)
29-29: LGTM: Import of admin CRUD section scope.The import aligns with the PR's objective of implementing scoped exports.
74-74: Verify the scope compatibility.The change from direct provider export to scoped export is aligned with the refactoring goal. However, we should verify that the
adminCrudSectionScopeis compatible with all consumers ofadminCrudQueries.Let's verify the usage of this provider:
✅ Verification successful
Scope compatibility verified successfully
The scoped export is compatible with all consumers as they are part of the same admin-crud section hierarchy and use standard provider functionality that is preserved in the scoped export.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential incompatibilities with the new scoped export # Find all files that import or use adminCrudQueries rg -l "adminCrudQueries" --type ts # Check for any direct provider usage that might break with scoped exports ast-grep --pattern 'adminCrudQueries: adminCrudQueriesProvider'Length of output: 319
Script:
#!/bin/bash # Check how adminCrudQueries is used in the consumer files rg "adminCrudQueries" -B 2 -A 2 packages/react-generators/src/generators/admin/admin-crud-list/index.ts packages/react-generators/src/generators/admin/admin-crud-edit/index.ts # Look for scope configurations rg "Scope|scope" -B 2 -A 2 packages/react-generators/src/generators/admin/admin-crud-{list,edit,queries}/index.tsLength of output: 12196
packages/project-builder-server/src/compiler/backend/models.ts (1)
100-101: LGTM! The change aligns with the scoped exports refactoring.The switch from feature-based references to direct model name references (
modelNameandforeignModelName) simplifies the relationship definition and aligns well with the PR's objective of implementing scoped exports.Let's verify that all model relationships are properly updated to use the new direct naming approach:
✅ Verification successful
✅ Verified: Model relationship changes are consistent across the codebase
The remaining feature-based references in the codebase serve different purposes (feature lookup, UI rendering) and don't conflict with the new direct model naming approach. The changes to
modelNameandforeignModelNameappear to be properly isolated to model relationship definitions.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining feature-based model references that might have been missed # Search for potential feature-based model references rg -l "getFeatureByIdOrThrow|FeatureUtils.*model" --type ts # Search for any TODO/FIXME comments related to feature or model references rg -l "TODO.*feature.*model|FIXME.*feature.*model" --type tsLength of output: 455
Script:
#!/bin/bash # Check the context of feature-based model references in backend compiler rg "getFeatureByIdOrThrow|FeatureUtils.*model" -C 3 packages/project-builder-server/src/compiler/backend/feature.ts # Look for any model relationship definitions similar to the changed code ast-grep --pattern 'modelName: $$.name'Length of output: 372
packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (2)
7-7: LGTM: Import addition aligns with the refactoring goalsThe addition of
projectScopeimport is necessary for implementing the new scoped exports pattern.
135-135: LGTM: Consistent implementation of scoped exportsThe modification to use
yogaPluginProvider.export(projectScope)maintains consistency with the new scoped exports pattern.Let's verify that all dependent modules are updated to handle the scoped provider:
✅ Verification successful
Verification complete: No dependent module updates needed
The dependent modules use
yogaPluginSetupProviderthrough proper dependency injection and don't directly interact with the modifiedyogaPluginexport, so no updates are required.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for direct usage of yogaPluginProvider to ensure all instances are updated rg -l "yogaPluginProvider\s*[^.]" --type ts # Search for imports of the yoga plugin to identify potential affected modules rg -l "from.*yoga-plugin" --type tsLength of output: 291
Script:
#!/bin/bash # Check how yoga-plugin is imported and used in pothos modules echo "=== pothos/index.ts ===" rg "from.*yoga-plugin|yogaPlugin" packages/fastify-generators/src/generators/pothos/pothos/index.ts -C 2 echo -e "\n=== pothos-sentry/index.ts ===" rg "from.*yoga-plugin|yogaPlugin" packages/fastify-generators/src/generators/pothos/pothos-sentry/index.ts -C 2Length of output: 2179
packages/fastify-generators/src/generators/prisma/prisma-field/index.ts (2)
Line range hint
46-85: Provider changes align with scoped exports refactoringThe implementation correctly removes the previous provider pattern and returns an empty object for
prismaFieldingetProviders, which aligns with the PR's objective of implementing scoped exports.
Line range hint
1-20: Verify imports for scoped exports patternSince this PR implements scoped exports to replace hoisted/peer providers, let's verify if any other imports need to be updated to align with the new pattern.
✅ Verification successful
Imports are correctly structured for scoped exports
The imports in this file are consistent with the new scoped exports pattern. The file correctly uses relative imports for
prismaModelProviderand only imports necessary utilities from@halfdomelabs/sync, aligning with the PR's objective of replacing hoisted/peer providers with scoped exports.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if other imports in related files follow the new scoped exports pattern # Search for similar import patterns in related files rg --type typescript "import.*prismaModelProvider.*" ./packages/fastify-generators/src/generators/ # Check for any remaining hoisted/peer provider imports rg --type typescript "createProviderType|Provider.*from.*@halfdomelabs/sync" ./packages/fastify-generators/src/Length of output: 284
Script:
#!/bin/bash # Search for provider-related imports and model provider usage rg "import.*prismaModelProvider" -g "*.ts" ./packages/fastify-generators/src/ # Check for any remaining provider imports from sync package rg "import.*from.*@halfdomelabs/sync" -g "*.ts" ./packages/fastify-generators/src/ # Look for potential provider exports rg "export.*Provider" -g "*.ts" ./packages/fastify-generators/src/Length of output: 20128
packages/sync/src/core/engine/dependency-map.ts (3)
122-124: Verify compatibility ofArray.prototype.findLastmethodThe use of
Array.prototype.findLastmay not be supported in all target environments, as it was introduced in ES2022. Please ensure that the runtime environment supports ES2022 features or consider using a polyfill or an alternative implementation.
131-136: Review the logic for resolving optional dependencies with export namesThe condition
if (!optional || exportName)ensures that a dependency with anexportNamemust be resolved, even if it's marked as optional. Is this the intended behavior? Should optional dependencies with anexportNamebe allowed to fail resolution without throwing an error?
209-222: LGTM:resolveTaskDependenciesfunction is well implementedThe
resolveTaskDependenciesfunction effectively builds the dependency map and integrates well with the new scoped provider resolution logic. The code is clear, and the recursion is properly handled.packages/sync/src/core/engine/dependency-map.unit.test.ts (2)
11-13: Verify thatcreateProviderTypesupports options parameterEnsure that the
createProviderTypefunction accepts an options parameter as used when creatingreadOnlyProvider. IfcreateProviderTypedoes not support options, this could lead to an error during tests.
310-329: Tests correctly handle error scenarios for duplicate provider exportsThe test cases for detecting duplicate provider exports within the same scope are appropriately designed. The error handling and assertions are correctly implemented.
packages/core-generators/src/providers/scopes.ts (1)
3-11: Well-structured scope hierarchy!The implementation establishes a clear distinction between project-wide and feature-specific scopes, which aligns well with the PR's objective of implementing scoped exports.
packages/fastify-generators/src/generators/pothos/index.ts (1)
11-11: LGTM! Clean provider export additionThe new export statement correctly exposes the scoped providers while maintaining the existing module structure.
packages/fastify-generators/src/generators/prisma/prisma-enum/index.ts (1)
Line range hint
22-24: Verify the empty prismaEnum provider objectThe provider returns an empty object
{}forprismaEnum. This seems unusual and might indicate incomplete refactoring from the old provider system to the new scoped exports.Let's check if this pattern exists elsewhere:
✅ Verification successful
Empty provider object is a valid pattern
The empty provider object
prismaEnum: {}follows an established pattern in the codebase where generators register their presence without exposing specific methods. This is used by multiple other generators likefastifyVitest,prismaFileTransformer, and others.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for similar patterns of empty provider objects rg -U "getProviders.*\(\).*=>.*\({[\s\n]*[a-zA-Z]+:[\s\n]*{[\s\n]*}[\s\n]*}\)" --type tsLength of output: 270
Script:
#!/bin/bash # Get the complete implementation of the prisma-enum generator ast-grep --pattern 'return { getProviders: () => $$$ }' # Search for similar generator patterns rg 'getProviders.*=>' --type ts -A 2 # Check for any imports or usages of prismaEnum provider rg "prismaEnum" --type tsLength of output: 54905
packages/react-generators/src/generators/auth/auth-pages/index.ts (1)
35-35: LGTM! Verify integration with dependent modules.The change to use
projectScopefor exportingauthPagesaligns with the new scoped exports architecture. Since this is a project-wide component, usingprojectScopeis appropriate.Let's verify that all consumers of
authPagesare compatible with the new scoped export:✅ Verification successful
Verified: No compatibility issues with
authPagesscoped exportThe
authPagesprovider appears to be newly introduced with no existing consumers, making this change safe. UsingprojectScopeis appropriate for this authentication-related feature.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for imports and usages of authPages to ensure compatibility rg -l "authPages.*Provider" | xargs rg "authPages"Length of output: 161
Script:
#!/bin/bash # Search for any mentions of authPages across the codebase rg "authPages" -B 2 -A 2 # Find files that might be auth page components fd -t f "auth.*\.(tsx?|jsx?)$"Length of output: 2743
packages/react-generators/src/generators/auth0/auth0-components/index.ts (1)
3-3: LGTM! Verify Auth0 component accessibility.Using
projectScopefor Auth0 components is appropriate as these are typically needed throughout the project. The implementation is consistent with the new scoped exports architecture.Let's verify that Auth0 components remain accessible to all necessary parts of the application:
Also applies to: 22-22
✅ Verification successful
Auth0 components accessibility verified successfully
The change to use
projectScopefor Auth0 components is safe and maintains proper accessibility throughout the project. The components are correctly exposed through path aliases and remain accessible to all necessary parts of the application, particularly in admin layouts where they are actively used.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for Auth0 component imports and ensure they're accessible rg -l "RequireAuth.*Component" | xargs rg "import.*RequireAuth"Length of output: 192
Script:
#!/bin/bash # Search for Auth0-related components and imports with broader patterns echo "=== Searching for Auth0 components ===" rg -l "auth0|Auth0|authentication" --type ts echo -e "\n=== Checking imports with auth patterns ===" rg "import.*auth|import.*Auth" --type ts echo -e "\n=== Checking path alias configuration ===" fd "tsconfig.*json" --type f --exec cat {}Length of output: 26595
packages/project-builder-server/src/compiler/backend/index.ts (1)
38-38: LGTM! Verify removal of hoisted providersThe simplified destructuring aligns with the PR's objective of removing hoisted providers in favor of scoped exports.
Let's verify no remaining references to hoisted providers exist:
✅ Verification successful
✅ Hoisted providers successfully removed
Verification complete. No remaining references to hoisted providers found in the codebase. The only provider-related occurrences are unrelated type system imports and UI labels.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to hoisted providers rg -i "hoisted.*provider" packages/project-builder-server/Length of output: 60
Script:
#!/bin/bash # Broader search for hoisted-related terms echo "=== Searching for 'hoisted' ===" rg -i "hoisted" packages/project-builder-server/ -B2 -A2 echo -e "\n=== Searching for provider patterns ===" rg -i "provider" packages/project-builder-server/ -B2 -A2 echo -e "\n=== Looking for provider-related class/interface definitions ===" ast-grep --pattern 'class $_ implements Provider' ast-grep --pattern 'interface $_ extends Provider' ast-grep --pattern 'class $_Provider'Length of output: 2343
packages/react-generators/src/generators/core/react-proxy/index.ts (2)
1-4: LGTM! Import of projectScopeThe addition of projectScope import aligns with the new scoped exports pattern.
33-33: LGTM! Scoped export implementationThe export has been properly updated to use projectScope, maintaining consistency with the new provider scoping system.
packages/fastify-generators/src/generators/email/fastify-postmark/index.ts (2)
3-3: LGTM! Import of projectScopeThe addition of projectScope import is consistent with the refactoring pattern.
30-30: LGTM! Scoped export implementationThe fastifyPostmark provider export has been properly updated to use projectScope.
packages/react-generators/src/generators/admin/admin-crud-column/index.ts (1)
24-24: Verify scope requirements for adminCrudDisplayContainerWhile the export has been updated to use the export() method, it doesn't include projectScope unlike other providers. Please verify if this is intentional or if it should follow the same pattern as other exports.
Let's check how other admin CRUD components handle their exports:
packages/fastify-generators/src/generators/core/fastify-scripts/index.ts (2)
1-5: LGTM: Clean import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
33-33: LGTM: Proper implementation of scoped exportThe export modification correctly uses the provider's
exportmethod withprojectScope.packages/react-generators/src/generators/admin/admin-home/index.ts (1)
3-3: LGTM: Clean import of projectScopeThe addition of
projectScopeimport is consistent with the PR's pattern.packages/react-generators/src/generators/core/react-logger/index.ts (2)
8-8: LGTM: Clean import of projectScopeThe addition of
projectScopeimport is consistent with the PR's pattern.
40-40: LGTM: Well-typed scoped export implementationThe export modification correctly uses the provider's
exportmethod withprojectScopeand maintains proper typing through theReactLoggerProviderinterface.packages/fastify-generators/src/generators/email/fastify-sendgrid/index.ts (1)
3-3: LGTM: Clean import of projectScopeThe addition of
projectScopeimport is consistent with the PR's pattern.packages/fastify-generators/src/generators/auth/password-hasher-service/index.ts (2)
6-6: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
36-36: Verify password hasher service isolationThe scoped export ensures proper isolation of the password hasher service. However, since this is a security-critical service, we should verify that it's properly isolated and can only be accessed by authorized components.
Let's verify the usage of this service:
✅ Verification successful
Password hasher service isolation verified successfully
The password hasher service maintains proper isolation within the auth module, with access limited to authorized components only. The service is only referenced by the password transformer component, which is an appropriate consumer within the auth context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the password hasher service is only imported by authorized components # Expected: Only auth-related components should import this service # Search for imports of password hasher service rg -l "from.*%password-hasher-service" # Search for direct imports of the service file rg -l "from.*password-hasher\.service"Length of output: 166
Script:
#!/bin/bash # Search for any reference to password hasher rg -l "passwordHasher" # Look for the service implementation ast-grep --pattern 'class $_ implements PasswordHasherService { $$$ }' # Search for any password-related service definitions rg -l "PasswordHasherService"Length of output: 374
packages/react-generators/src/generators/auth/auth-components/index.ts (2)
5-5: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
36-36: LGTM: Scoped export of auth componentsThe scoped export of auth components ensures they are properly isolated within the project scope.
packages/react-generators/src/generators/auth/auth-layout/index.ts (2)
3-3: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
35-35: LGTM: Scoped export of auth layoutThe scoped export of auth layout ensures it is properly isolated within the project scope.
packages/fastify-generators/src/generators/auth/user-session-types/index.ts (2)
5-5: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
34-34: Verify session types isolationThe scoped export ensures proper isolation of user session types. Since this involves session management, we should verify that these types are only accessible to authorized components.
Let's verify the usage of these types:
✅ Verification successful
Session types isolation verified successfully
The user session types are properly isolated and only imported by authorized authentication components (auth plugin and user session service).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that user session types are only imported by authorized components # Expected: Only auth-related components should import these types # Search for imports of user session types rg -l "from.*%user-session-types" # Search for direct imports of the types file rg -l "from.*user-session\.types"Length of output: 269
packages/react-generators/src/generators/auth0/auth0-apollo/index.ts (3)
1-4: LGTM: Import changes align with new scoped exports patternThe addition of
projectScopeimport is consistent with the PR's objective to implement scoped exports.
29-29: LGTM: Export modification follows new patternThe export now uses
projectScope, consistent with the refactoring objective.
19-19: Consider documenting the provider type name changeThe change from 'auth0Apollo' to 'auth0-apollo' follows kebab-case convention, which is good. However, this type of change might affect existing consumers.
Let's check for any existing usage:
packages/react-generators/src/generators/auth/auth-identify/index.ts (2)
3-6: LGTM: Clean import restructuringThe imports are well-organized, grouping related imports from '@halfdomelabs/core-generators'.
34-34: LGTM: Export follows new scoped patternThe export modification aligns with the PR's objective of implementing scoped exports.
packages/react-generators/src/generators/core/react-not-found-handler/index.ts (2)
3-3: LGTM: Clean import additionThe projectScope import is correctly placed with other core imports.
39-39: LGTM: Export modification follows patternThe export change to use projectScope is consistent with the refactoring objective.
packages/core-generators/src/generators/node/node-git-ignore/index.ts (2)
25-25: LGTM: Export follows new patternThe export modification to use projectScope is consistent with the refactoring objective.
8-9: Verify import path consistencyThe projectScope is imported from '@src/providers/scopes.js' while other files import it from '@halfdomelabs/core-generators'.
Let's check for consistency:
✅ Verification successful
Import paths are correctly structured
The different import paths are intentional and correct:
- Within core-generators: Uses internal path '@src/providers/scopes.js'
- External packages: Import from published package '@halfdomelabs/core-generators'
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check all projectScope imports rg -A 1 "import.*projectScope" --type tsLength of output: 2357
packages/react-generators/src/generators/core/react-error-boundary/index.ts (1)
4-4: LGTM: Consistent implementation of scoped exportsThe changes correctly implement the new scoped exports pattern by:
- Importing
projectScopefrom core-generators- Using
reactErrorBoundaryProvider.export(projectScope)for provider resolutionThis aligns with the PR's objective of replacing hoisted providers with scoped exports.
Also applies to: 36-36
packages/project-builder-server/src/compiler/admin/sections.ts (1)
39-39: LGTM: Clean removal of hoisted providersThe change correctly removes the dependency on hoisted providers by using
projectDefinitioninstead ofparsedProject, aligning with the PR's objective of implementing scoped exports.packages/fastify-generators/src/generators/core/fastify-health-check/index.ts (1)
4-4: LGTM: Consistent implementation of scoped exportsThe changes correctly implement the new scoped exports pattern by:
- Importing
projectScopefrom core-generators- Using
fastifyHealthCheckProvider.export(projectScope)for provider resolutionThis aligns with the PR's objective of replacing hoisted providers with scoped exports.
Also applies to: 36-36
packages/fastify-generators/src/generators/prisma/prisma-relation-field/index.ts (2)
20-21: Improved schema clarity with explicit model namingThe split of
modelRefintomodelNameandforeignModelNamemakes the relationship between models more explicit and self-documenting.
37-40: Verify model reference consistencyThe dependency population logic has been updated to match the new schema fields. Please ensure that all consumers of this generator have been updated to provide both
modelNameandforeignModelNameinstead ofmodelRef.✅ Verification successful
Migration to new schema fields is properly handled
The codebase shows proper adaptation to the new schema fields. The form component (ModelRelationForm.tsx) has been updated to convert from modelRef to the new modelName parameter, and no instances of direct usage with the old parameter style were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of PrismaRelationFieldGenerator to verify they've been updated rg -A 5 "PrismaRelationFieldGenerator"Length of output: 876
Script:
#!/bin/bash # Search for imports of the generator rg -l "from.*prisma-relation-field'" rg -l "require.*prisma-relation-field'" # Search for any remaining references to modelRef in relation context rg -B 3 -A 3 "modelRef" # Search for actual instantiations with modelName and foreignModelName ast-grep --pattern 'modelName: $_'Length of output: 9908
Script:
#!/bin/bash # Search for generator configuration or usage patterns rg -B 5 -A 5 "prismaModel\.dependency\(\)\.reference|foreignModel\.dependency\(\)\.reference" # Search for any direct instantiations ast-grep --pattern 'new PrismaRelationFieldGenerator' ast-grep --pattern 'createGeneratorWithChildren({$$$})'Length of output: 70406
packages/react-generators/src/generators/auth0/react-auth0/index.ts (2)
3-3: LGTM: Added projectScope importImport aligns with the PR objective of implementing scoped exports.
33-33: Verify provider scope implementationThe change from direct provider export to scoped export using
projectScopealigns with the PR's objective. This ensures consistent provider resolution within the project scope.✅ Verification successful
Provider scope implementation verified
The implementation of
projectScopein the react-auth0 provider is consistent with all other auth providers in the codebase. All auth-related providers use the sameprovider.export(projectScope)pattern.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify consistent usage of projectScope across auth providers rg -l "projectScope.*export" "packages/react-generators/src/generators/auth"Length of output: 76
Script:
#!/bin/bash # List auth-related files to verify structure echo "=== Auth-related files ===" fd . packages/react-generators/src/generators/auth # Look for provider exports echo -e "\n=== Provider exports ===" rg "export.*provider" packages/react-generators/src/generators/auth # Search for projectScope usage echo -e "\n=== ProjectScope usage ===" rg "projectScope" packages/react-generators/src/generators/authLength of output: 4757
packages/react-generators/src/generators/core/react-datadog/index.ts (2)
5-5: LGTM: Added projectScope importImport aligns with the PR objective of implementing scoped exports.
38-38: Verify provider scope implementationThe change from direct provider export to scoped export using
projectScopealigns with the PR's objective. This ensures consistent provider resolution within the project scope.✅ Verification successful
Provider scope implementation verified successfully
The implementation follows the established pattern used across all core React providers in the codebase, where providers are exported with project scope for consistent resolution.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify consistent usage of projectScope across core providers rg -l "projectScope.*export" "packages/react-generators/src/generators/core"Length of output: 76
Script:
#!/bin/bash # Search for provider files in core directory echo "=== Provider files ===" fd provider "packages/react-generators/src/generators/core" echo -e "\n=== Export patterns in provider files ===" rg "\.export\(" "packages/react-generators/src/generators/core" echo -e "\n=== Project scope usage ===" rg "projectScope" "packages/react-generators/src/generators/core"Length of output: 5985
packages/react-generators/src/generators/core/react-utils/index.ts (2)
3-6: LGTM! Import of projectScope added correctlyThe addition of
projectScopealigns with the PR's objective of implementing scoped exports.
41-41: LGTM! Provider export updated to use projectScopeThe modification to use
projectScopein the export is consistent with the refactoring pattern.packages/fastify-generators/src/generators/pothos/pothos-prisma/index.ts (2)
3-3: LGTM! Import of projectScope added correctlyThe addition of
projectScopealigns with the PR's objective of implementing scoped exports.
36-36: LGTM! Provider export updated to use projectScopeThe modification to use
projectScopein the export is consistent with the refactoring pattern.packages/react-generators/src/generators/auth/auth-service/index.ts (2)
5-5: LGTM! Import of projectScope added correctlyThe addition of
projectScopealigns with the PR's objective of implementing scoped exports.
39-39: LGTM! Provider export updated to use projectScopeThe modification to use
projectScopein the export is consistent with the refactoring pattern.packages/fastify-generators/src/generators/auth/auth-roles/index.ts (2)
5-5: LGTM! Import of projectScope added correctlyThe addition of
projectScopealigns with the PR's objective of implementing scoped exports.
49-49: LGTM! Provider export updated to use projectScopeThe modification to use
projectScopein the export is consistent with the refactoring pattern.packages/fastify-generators/src/generators/auth/auth/index.ts (3)
3-7: LGTM! Import changes align with the new scoping strategy.The restructured imports properly separate type imports and add the new
projectScopeimport needed for scoped exports.
46-46: LGTM! Proper implementation of scoped exports for authSetup.The export now correctly uses
projectScopefor theauthSetupProvider, aligning with the new scoping strategy.
67-67: LGTM! Proper implementation of scoped exports for auth.The export now correctly uses
projectScopefor theauthProvider, maintaining consistency with the new scoping approach.packages/react-generators/src/generators/core/react-error/index.ts (2)
8-8: LGTM! Consistent import of projectScope.The addition of
projectScopeimport aligns with the new scoping strategy.
40-40: LGTM! Proper implementation of scoped exports for reactError.The export correctly uses
projectScopefor thereactErrorProvider, maintaining consistency with the new scoping approach.packages/project-builder-lib/src/compiler/app-compiler-spec.ts (1)
64-64: LGTM! Documentation updated to reflect removal of hoisted providers.The comment now correctly focuses on the core functionality of adding children to the compilation flow, aligning with the removal of hoisted providers in favor of scoped exports.
packages/fastify-generators/src/generators/prisma/prisma-model/index.ts (2)
1-1: LGTM! Proper restructuring of imports and generator creation.The changes correctly implement:
- Addition of
projectScopeimport- Switch to
createGeneratorWithTasksfor better task managementAlso applies to: 3-3
73-104: LGTM! Well-structured task implementation with proper scoping.The task implementation:
- Correctly uses the prisma dependency
- Properly implements scoped exports with both basic export and project scope
- Maintains the core functionality while simplifying the structure
The chained export
.export().andExport(projectScope, descriptor.name)is a nice pattern that provides both global and scoped accessibility.packages/core-generators/src/generators/node/eslint/index.ts (1)
10-10: LGTM! Scoped export implementation looks correct.The addition of
projectScopeand its usage ineslintProvider.export()aligns with the PR's objective of implementing scoped exports.Also applies to: 33-33
packages/react-generators/src/generators/core/react-tailwind/index.ts (1)
5-5: LGTM! Consistent implementation of scoped exports.The addition of
projectScopeand its usage inreactTailwindProvider.export(projectScope)follows the established pattern for implementing scoped exports.Also applies to: 40-40
packages/react-generators/src/generators/admin/admin-bull-board/index.ts (1)
2-2: LGTM! Proper implementation of scoped exports.The addition of
projectScopeand its usage inadminBullBoardProvider.export(projectScope)correctly implements the new scoped exports pattern.Also applies to: 40-40
packages/fastify-generators/src/generators/stripe/fastify-stripe/index.ts (1)
3-3: LGTM! Consistent implementation of scoped exports.The changes correctly implement the new scoped exports pattern by:
- Importing
projectScopefrom core-generators- Using
.export(projectScope)in the exports sectionAlso applies to: 39-39
packages/fastify-generators/src/generators/core/request-context/index.ts (1)
6-6: Verify compatibility of readOnly provider with scoped exports.The changes implement the scoped exports pattern correctly. However, since this provider is marked as
isReadOnly: true, we should verify that scoped exports work as expected with read-only providers.Let's check for any special handling of read-only providers in the codebase:
Also applies to: 64-64
✅ Verification successful
ReadOnly providers are fully compatible with scoped exports
The codebase shows consistent and successful usage of readOnly providers with scoped exports across multiple core services, confirming their compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other readOnly providers using scoped exports ast-grep --pattern 'createProviderType<$_>($_, { isReadOnly: true })' # Search for any special handling of readOnly providers in the export implementation rg -l "isReadOnly.*export.*scope"Length of output: 4301
Script:
#!/bin/bash # Search for projectScope usage in files containing readOnly providers rg -B 5 -A 5 "projectScope" $(rg -l "isReadOnly: true") # Search for any implementation details about scoped exports with readOnly providers ast-grep --pattern 'export function $_($$_) { $$$ projectScope $$$ isReadOnly $$$ }' # Search for any restrictions or special handling in the provider creation ast-grep --pattern 'function createProviderType<$_>($_, $opts) { $$$ projectScope $$$ isReadOnly $$$ }'Length of output: 25066
packages/react-generators/src/generators/core/react-app/index.ts (1)
8-8: LGTM! Consistent implementation of scoped exports.The changes correctly implement the new scoped exports pattern by:
- Importing
projectScopefrom core-generators- Using
.export(projectScope)in the exports sectionAlso applies to: 42-42
packages/react-generators/src/generators/admin/admin-components/index.ts (1)
6-6: LGTM! Verify provider usage across dependent modules.The implementation correctly introduces scoped exports for the
adminComponentsprovider. The changes align with the broader refactoring effort to replace hoisted providers.Let's verify that all dependent modules are compatible with this scoped export:
Also applies to: 33-33
✅ Verification successful
Provider usage verified across dependent modules
The scoped export is compatible with all dependent modules. Both
admin-crud-embedded-formandadmin-crud-embedded-inputuse the provider directly in their dependencies configuration, which will work seamlessly with the scoped version.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for direct usage of adminComponentsProvider to ensure all consumers are updated rg -l "adminComponentsProvider" --type tsLength of output: 277
Script:
#!/bin/bash # Check the actual usage in dependent files echo "=== admin-crud-embedded-form/index.ts ===" rg "adminComponentsProvider" packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts -B2 -A2 echo -e "\n=== admin-crud-embedded-input/index.ts ===" rg "adminComponentsProvider" packages/react-generators/src/generators/admin/admin-crud-embedded-input/index.ts -B2 -A2Length of output: 1385
packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (1)
1-1: LGTM! Setup task exports correctly configured.The setup task's export is correctly configured using the provider's export method.
Also applies to: 62-64
packages/fastify-generators/src/generators/pothos/pothos-prisma-list-query/index.ts (2)
19-19: LGTM! Field provider correctly scoped.The implementation correctly uses the dedicated
pothosFieldScopefor the field provider export.Also applies to: 36-36
98-98: Verify scope configuration impact.The addition of
pothosFieldScopeto the generator's scopes array is correct. This ensures proper provider resolution within the generator's context.Let's verify that all dependent generators are compatible with this scope configuration:
✅ Verification successful
Scope configuration is correctly aligned across all Pothos generators
All related Pothos generators (
pothos-prisma-crud-mutation,pothos-prisma-object,pothos-prisma-get-query) consistently use the same scope configuration withpothosFieldScope. The implementation is uniform and correct.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other generators that might need similar scope configuration rg -l "createGeneratorWithTasks.*pothosField" --type tsLength of output: 57
Script:
#!/bin/bash # Search for pothosFieldScope usage rg "pothosFieldScope" --type ts -l # Search for Pothos-related generators fd "pothos.*\.ts$" -t f # Search for scope configurations in Pothos files rg "scopes.*\[" --type ts packages/fastify-generators/src/generators/pothosLength of output: 1111
packages/fastify-generators/src/generators/prisma/prisma-utils/index.ts (1)
4-4: LGTM: Consistent implementation of scoped exportsThe changes properly implement the new scoped exports pattern by importing and utilizing
projectScopein the provider export.Also applies to: 74-74
packages/fastify-generators/src/generators/bull/bullmq/index.ts (1)
3-3: LGTM: Consistent implementation of scoped exportsThe changes properly implement the new scoped exports pattern by importing and utilizing
projectScopein the provider export.Also applies to: 36-36
packages/react-generators/src/generators/admin/admin-layout/index.ts (1)
3-3: LGTM: Consistent implementation of scoped exportsThe changes properly implement the new scoped exports pattern by importing and utilizing
projectScopein the provider export.Also applies to: 58-58
packages/react-generators/src/generators/auth/auth-apollo/index.ts (2)
1-4: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the PR's objective of implementing scoped exports.
31-31: LGTM: Scoped export implementationThe modification to use
projectScopein the export ensures proper scoping of the auth-apollo provider, aligning with the new dependency resolution strategy.packages/core-generators/src/generators/node/vitest/index.ts (2)
12-12: LGTM: Import of projectScopeThe addition of
projectScopeimport from scopes.js is consistent with the project-wide refactoring.
41-41: LGTM: Scoped export implementationThe modification to use
projectScopein the vitest export aligns with the new dependency resolution strategy.packages/fastify-generators/src/generators/core/fastify-redis/index.ts (2)
6-6: LGTM: Import of projectScopeThe addition of
projectScopeimport maintains consistency with the project-wide refactoring.
45-45: LGTM: Scoped export implementationThe modification to use
projectScopein the fastifyRedis export aligns with the new dependency resolution strategy.packages/react-generators/src/generators/core/react-sentry/index.ts (3)
6-6: LGTM: Import of projectScopeThe addition of
projectScopeimport is consistent with the project-wide refactoring.
42-42: LGTM: Scoped export implementationThe modification to use
projectScopein the reactSentry export aligns with the new dependency resolution strategy.
Line range hint
87-91: LGTM: Provider implementationThe implementation of the reactSentry provider maintains the necessary functionality while adapting to the new scoping system.
packages/fastify-generators/src/generators/vitest/prisma-vitest/index.ts (2)
43-43: LGTM! Scoped export implementation looks correct.The modification to use
prismaVitestProvider.export(projectScope)aligns with the PR's objective of implementing scoped exports.
4-4: Address TODO: Add tests for the prisma-vitest generator.This TODO comment indicates missing test coverage. Given the recent changes to the export mechanism, it's particularly important to ensure proper test coverage.
Would you like me to help generate test cases for this generator? I can create a GitHub issue to track this task.
packages/fastify-generators/src/generators/pothos/pothos-auth/index.ts (2)
107-107: LGTM! Scoped export implementation looks correct.The modification to use
pothosAuthProvider.export(projectScope)aligns with the PR's objective of implementing scoped exports.
Line range hint
112-112: Address TODO: Implement role validation in formatAuthorizeConfig.The current implementation lacks role validation, which could lead to runtime issues if invalid roles are provided.
Would you like me to help implement the role validation logic? I can suggest an implementation that validates roles against a predefined set of valid roles.
packages/react-generators/src/generators/auth0/auth0-hooks/index.ts (1)
30-30: LGTM! Scoped export implementation looks correct.The modification to use
authHooksProvider.export(projectScope)aligns with the PR's objective of implementing scoped exports.packages/fastify-generators/src/generators/core/logger-service/index.ts (2)
63-64: LGTM! Scoped export implementation looks correct.The modifications to use
.export(projectScope)for both providers align with the PR's objective of implementing scoped exports.
Line range hint
75-75: Verify the fixed package versions for security and compatibility.The package versions are fixed to specific versions:
- pino: 9.5.0
- pino-pretty: 13.0.0
Let's verify these versions for any known vulnerabilities or newer stable releases.
Also applies to: 80-80
✅ Verification successful
Current package versions are secure and compatible
- pino@9.5.0 and pino-pretty@13.0.0 are recent, stable versions
- No security advisories found
- Latest pino version (9.6.0) only contains dev dependency updates and non-breaking features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for latest versions and security advisories for pino packages # Check NPM for latest versions echo "Latest versions:" npm view pino version npm view pino-pretty version # Check for security advisories echo -e "\nSecurity advisories:" npm audit pino@9.5.0 pino-pretty@13.0.0 --json | jq '.advisories'Length of output: 587
Script:
#!/bin/bash # Check GitHub releases and security advisories for pino # Get release notes for pino 9.6.0 echo "Pino 9.6.0 Release Notes:" gh release view v9.6.0 --repo pinojs/pino # Check security advisories echo -e "\nSecurity Advisories:" gh api /repos/pinojs/pino/security-advisories --jq '.[] | select(.state=="published")'Length of output: 3100
packages/react-generators/src/generators/core/react-config/index.ts (1)
9-9: LGTM! Consistent with the new scoped exports pattern.The change from direct provider export to scoped export using
projectScopealigns with the PR's objective of implementing scoped exports.Also applies to: 47-47
packages/fastify-generators/src/generators/bull/fastify-bull-board/index.ts (1)
3-3: LGTM! Well-structured changes with improved code organization.The changes correctly implement scoped exports and improve code organization by:
- Adding projectScope for scoped exports
- Refactoring moduleFolder definition for better maintainability
Also applies to: 41-41, 53-54
packages/react-generators/src/generators/admin/admin-crud-embedded-input/index.ts (1)
42-42:⚠️ Potential issueAdd projectScope parameter to export() call for consistency.
The export() call should include the projectScope parameter to maintain consistency with the new scoped exports pattern being implemented across the codebase.
Apply this diff:
- adminCrudEmbeddedInput: adminCrudEmbeddedInputProvider.export(), + adminCrudEmbeddedInput: adminCrudEmbeddedInputProvider.export(projectScope),Let's verify if there are other instances of export() calls without projectScope:
✅ Verification successful
Confirmed: Add projectScope parameter to export() call
The codebase consistently uses
export(projectScope)in generator implementations. This change maintains consistency with the established pattern.
- Location: packages/react-generators/src/generators/admin/admin-crud-embedded-input/index.ts
Apply this diff:
- adminCrudEmbeddedInput: adminCrudEmbeddedInputProvider.export(), + adminCrudEmbeddedInput: adminCrudEmbeddedInputProvider.export(projectScope),🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for export() calls without projectScope rg -U "export\(\s*\)" --type tsLength of output: 3183
Script:
#!/bin/bash # Search for export() calls with parameters and export method definitions rg -U "export\([^)]+\)" --type ts ast-grep --pattern "export($$$) { $$$ }"Length of output: 16590
packages/react-generators/src/generators/core/react-router/index.ts (1)
8-8: LGTM! Consistent implementation of scoped exports.The changes correctly implement scoped exports using
projectScope, aligning with the PR's objective of replacing hoisted/peer providers.Also applies to: 62-64
packages/sync/src/core/engine/generator-runner.ts (1)
13-13: LGTM! Simplified dependency resolution.The changes streamline the dependency resolution process by replacing
buildEntryDependencyMapRecursivewithresolveTaskDependencies, reducing complexity while maintaining functionality.Let's verify that all dependencies are properly resolved:
Also applies to: 23-23
✅ Verification successful
Dependencies are properly resolved with improved API design
The new implementation maintains comprehensive dependency resolution while simplifying the public API. The internal implementation properly handles all cases including required/optional dependencies, scoped providers, and nested inheritance, with proper error handling for missing dependencies and duplicates.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any potential dependency resolution issues. # Test: Search for dependency-related error handling patterns. rg -A 5 "Could not resolve (required )?dependency" --type tsLength of output: 1610
Script:
#!/bin/bash # Check for any remaining references to the old function rg "buildEntryDependencyMapRecursive" --type ts # Look at the implementation of resolveTaskDependencies ast-grep --pattern 'export function resolveTaskDependencies($_) { $$$ }'Length of output: 394
Script:
#!/bin/bash # Get the complete dependency-map.ts file cat packages/sync/src/core/engine/dependency-map.ts # Check usage of resolveTaskDependencies rg -A 5 "resolveTaskDependencies" --type tsLength of output: 14055
packages/fastify-generators/src/generators/pothos/pothos-prisma-get-query/index.ts (1)
26-26: LGTM! Consistent implementation of scoped exports for Pothos fields.The changes correctly implement scoped exports using
pothosFieldScopeand properly configure the generator with the required scope.Let's verify the consistent usage of Pothos field scopes:
Also applies to: 44-44, 135-135
✅ Verification successful
Verified: Pothos field scopes are consistently implemented
All generators that produce Pothos fields correctly use
pothosFieldScope, while supporting generators appropriately omit it based on their responsibilities.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistent usage of Pothos field scopes. # Test: Search for patterns related to Pothos field scopes. ast-grep --pattern 'export(pothosFieldScope)' rg -A 2 "scopes: \[.*pothosFieldScope" --type tsLength of output: 1487
Script:
#!/bin/bash # Find all Pothos-related generators fd "pothos.*index.ts$" packages/fastify-generators/src/generators/pothos # Check the definition and export of pothosFieldScope ast-grep --pattern 'export const pothosFieldScope'Length of output: 521
Script:
#!/bin/bash # Find any Pothos generators that might be missing the scope rg "export default createGenerator\(" packages/fastify-generators/src/generators/pothos --type ts -A 3Length of output: 104
Script:
#!/bin/bash # Search for generator definitions with different patterns rg "createGenerator\(" packages/fastify-generators/src/generators/pothos --type ts -A 3 # Also check all index.ts files in pothos directory for any generator definitions fd "index.ts$" packages/fastify-generators/src/generators/pothos -x cat {}Length of output: 65675
packages/fastify-generators/src/generators/core/service-file/index.ts (2)
25-26: LGTM! Well-documented schema addition.The optional
idproperty is properly added to the schema with clear documentation explaining its purpose for referencing by other generators.
119-145: LGTM! Robust implementation of conditional scoped exports.The changes correctly implement:
- Conditional task creation based on the presence of
descriptor.id- Proper scoping using both
projectScopeanddescriptor.id- Appropriate error handling for missing output methods
Let's verify the consistent usage of service file scopes and IDs:
✅ Verification successful
Service file output provider implementation verified successfully
The implementation shows consistent usage across the codebase:
- Proper scoping with
projectScopeanddescriptor.id- Correct consumer usage in
pothos-prisma-crud-mutation- Robust error handling for missing methods
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistent usage of service file scopes and IDs. # Test: Search for patterns related to service file scopes and descriptor IDs. ast-grep --pattern 'serviceFileOutputProvider.export($_, $_)' rg "descriptor\.id" --type tsLength of output: 712
Script:
#!/bin/bash # Search for serviceFileOutputProvider usage and related patterns ast-grep --pattern 'serviceFileOutputProvider' ast-grep --pattern 'serviceFileOutput' rg "ServiceFileOutputProvider" --type tsLength of output: 1113
packages/project-builder-server/src/compiler/backend/services.ts (2)
47-49: LGTM! Simplified foreign model reference.The change simplifies the transformer output by directly using the model name when embedded transformers are present.
96-96: LGTM! Added unique service identifier.The addition of a unique identifier for each service model follows a consistent pattern and improves service resolution.
packages/fastify-generators/src/generators/auth/auth-context/index.ts (1)
45-45: LGTM! Implemented scoped export for auth context.The change properly scopes the auth context provider within the project scope, aligning with the new dependency resolution approach.
packages/react-generators/src/generators/auth/auth-hooks/index.ts (1)
46-46: LGTM! Implemented scoped export for auth hooks.The change properly scopes the auth hooks provider within the project scope, maintaining consistency with the new dependency resolution approach.
packages/sync/src/core/engine/generator-builder.ts (3)
33-33: LGTM! Added scopes property to GeneratorEntry interface.The addition of the
scopesproperty enables proper tracking of export scopes for each generator entry.
114-126: LGTM! Improved descriptor handling and task creation.The changes improve the clarity of descriptor handling and maintain a clean separation of concerns in task creation.
166-167: LGTM! Added scopes support to generator entry.The implementation properly handles scopes with fallback to an empty array, maintaining backward compatibility.
packages/fastify-generators/src/generators/pothos/pothos-prisma-object/index.ts (2)
52-56: LGTM! Appropriate scoping of exports.The exports are correctly scoped:
pothosPrismaObjectusespothosFieldScopeas it's field-level.pothosTypeOutputusesprojectScopewith a model-specific identifier.
151-151: LGTM! Consistent scope declaration.The generator correctly declares
pothosFieldScopein its scopes array, which aligns with its field-level exports.packages/fastify-generators/src/generators/core/error-handler-service/index.ts (1)
72-73: LGTM! Appropriate project-level scoping.The error handler service exports are correctly scoped to
projectScopeas error handling is a project-wide concern.Also applies to: 149-149
packages/sync/src/core/engine/dependency-sort.unit.test.ts (2)
54-56: LGTM! Consistent provider naming convention.Provider names now follow the kebab-case convention, which is more consistent with typical package naming practices.
62-62: LGTM! Consistent export method usage.All exports now correctly use the
export()method, aligning with the new scoping mechanism.Also applies to: 66-66, 108-108, 112-112, 117-117, 162-162, 166-166
packages/fastify-generators/src/generators/core/config-service/index.ts (1)
75-75: LGTM! Appropriate project-level scoping.The configuration service export is correctly scoped to
projectScopeas configuration is a project-wide concern.packages/react-generators/src/generators/core/react-components/index.ts (2)
6-6: LGTM: Import of projectScopeThe addition of
projectScopeimport aligns with the refactoring objective.
78-78: Verify the scoped export implementationThe export modification looks correct. However, let's verify that all consumers of
reactComponentsare compatible with the scoped export.✅ Verification successful
All consumers are compatible with scoped exports
The verification confirms that all consumers, including the plugin implementation, correctly use the scoped export pattern. No compatibility issues found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consumers of reactComponents provider # Search for imports and usage of reactComponents provider # Test 1: Find direct references to reactComponents rg -l "reactComponents(Provider)?" # Test 2: Find usage patterns of the provider ast-grep --pattern 'reactComponents: $_'Length of output: 1706
Script:
#!/bin/bash # Check import statements and usage patterns # Find import statements for reactComponents rg "import.*reactComponents" -A 2 # Check usage with more specific patterns ast-grep --pattern 'reactComponents.export($_)' # Look at the plugin implementation specifically cat "plugins/baseplate-plugin-storage/src/generators/react/upload-components/index.ts"Length of output: 17536
packages/fastify-generators/src/generators/core/request-service-context/index.ts (3)
8-8: LGTM: Import of projectScopeThe addition of
projectScopeimport is consistent with the refactoring pattern.
72-73: LGTM: Scoped export of requestServiceContextSetupThe export modification correctly implements the scoped export pattern.
174-175: LGTM: Scoped export of requestServiceContextThe export modification correctly implements the scoped export pattern.
packages/fastify-generators/src/generators/core/fastify-server/index.ts (2)
7-7: LGTM: Import of projectScopeThe addition of
projectScopeimport is consistent with the refactoring pattern.
60-60: Verify the scoped export implementationThe export modification looks correct. Let's verify the compatibility with consumers.
✅ Verification successful
Export implementation verified successfully
The scoped export is compatible with all existing consumers across the codebase, maintaining consistent provider patterns in all dependent modules.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consumers of fastifyServer provider # Search for imports and usage of fastifyServer provider # Test: Find usage patterns of the provider ast-grep --pattern 'fastifyServer: $_'Length of output: 40
Script:
#!/bin/bash # Search for fastifyServer mentions rg "fastifyServer" -A 2 # Find import/export patterns ast-grep --pattern 'import { $_ } from $_' # Look for provider implementation ast-grep --pattern 'export const fastifyServerProvider = $_'Length of output: 17403
packages/fastify-generators/src/generators/core/service-context/index.ts (3)
8-8: LGTM: Import of projectScopeThe addition of
projectScopeimport is consistent with the refactoring pattern.
60-60: LGTM: Scoped export of serviceContextSetupThe export modification correctly implements the scoped export pattern.
183-185: LGTM: Scoped export of serviceContextThe export modification correctly implements the scoped export pattern.
packages/project-builder-server/src/compiler/admin/crud/inputs.ts (2)
Line range hint
149-160: LGTM! Simplified parameter list and form reference.The removal of
crudSectionIdand direct usage ofdefinition.embeddedFormNamemakes the code cleaner and more maintainable.
Line range hint
166-188: LGTM! Consistent simplification of form reference.The changes align with the modifications in
adminCrudEmbeddedInputCompiler, maintaining consistency across the codebase.packages/project-builder-server/src/compiler/backend/graphql.ts (2)
11-18: LGTM! Improved import organization.Consolidating related PothosPrisma type imports enhances code readability and maintainability.
152-152: LGTM! Simplified service reference.The direct use of model name in
crudServiceReftemplate literal makes the code more straightforward.packages/react-generators/src/generators/core/react/index.ts (1)
13-13: LGTM! Implemented scoped exports.The addition of
projectScopeand modification of react provider export aligns with the PR objective of implementing scoped exports to replace hoisted/peer providers.Also applies to: 67-67
packages/fastify-generators/src/generators/pothos/pothos-prisma-crud-mutation/index.ts (2)
27-27: LGTM! Enhanced provider scoping.The implementation of
pothosFieldScopeand removal ofobjectTypeRefimproves the provider management system while simplifying the descriptor structure.Also applies to: 38-38, 49-49, 52-52
210-210: LGTM! Added proper field scoping.The addition of
pothosFieldScopeto the generator's scopes ensures proper isolation and management of field providers.packages/fastify-generators/src/generators/core/root-module/index.ts (2)
7-7: LGTM! Import of projectScopeThe addition of projectScope import aligns with the PR's objective to implement scoped exports.
60-60: Consistent implementation of scoped exportsThe modification of exports to use
export(projectScope)follows a consistent pattern:
- rootModule:
rootModuleProvider.export(projectScope)- rootModuleImport:
rootModuleImportProvider.export(projectScope)- appModule:
appModuleProvider.export(projectScope)This change aligns with the PR's objective to replace hoisted/peer providers with scoped exports.
Also applies to: 89-91, 119-119
packages/fastify-generators/src/generators/core/fastify/index.ts (2)
7-7: LGTM! Import of projectScopeThe addition of projectScope import aligns with the PR's objective to implement scoped exports.
171-171: Consistent implementation of scoped exportsThe modification of exports to use
export(projectScope)follows a consistent pattern:
- fastify:
fastifyProvider.export(projectScope)- fastifyOutput:
fastifyOutputProvider.export(projectScope)This change aligns with the PR's objective to replace hoisted/peer providers with scoped exports.
Also applies to: 232-234
packages/fastify-generators/src/generators/auth0/auth0-module/index.ts (2)
4-4: LGTM! Import of projectScopeThe addition of projectScope import aligns with the PR's objective to implement scoped exports.
53-54: Consistent implementation of scoped exportsThe modification of exports to use
export(projectScope)follows a consistent pattern:
- auth0Module:
auth0ModuleProvider.export(projectScope)- userSessionService:
userSessionServiceProvider.export(projectScope)This change aligns with the PR's objective to replace hoisted/peer providers with scoped exports.
packages/core-generators/src/generators/node/prettier/index.ts (2)
116-116: LGTM! Consistent implementation of scoped exportsThe modification of the prettier export to use
export(projectScope)aligns with the PR's objective to replace hoisted/peer providers with scoped exports.
20-20: Verify import path consistencyThe projectScope is imported from
@src/providers/scopes.jswhile other files import it from@halfdomelabs/core-generators. Verify if this difference in import paths is intentional.Run the following script to check import paths across the codebase:
✅ Verification successful
Import paths are consistently used based on package location
The difference in import paths is intentional and follows a common monorepo pattern:
- Files within
core-generatorsuse the internal path@src/providers/scopes.js- Files in other packages correctly import from the published package
@halfdomelabs/core-generators🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistency in projectScope import paths # Search for projectScope imports rg -A 1 "import.*projectScope" --type tsLength of output: 2357
packages/fastify-generators/src/generators/core/fastify-sentry/index.ts (1)
11-11: LGTM!The changes correctly implement scoped exports by importing and using projectScope in the fastifySentry export.
Also applies to: 122-122
packages/fastify-generators/src/generators/prisma/prisma/index.ts (1)
10-10: LGTM!The changes correctly implement scoped exports by:
- Importing projectScope
- Using it consistently in both prismaSchema and prismaOutput exports
Also applies to: 87-87, 218-218
packages/core-generators/src/generators/node/node/index.ts (1)
16-17: LGTM! Comprehensive implementation of scoped exports.The changes provide a thorough implementation of scoped exports by:
- Importing projectScope
- Configuring it in the scopes array
- Consistently applying it across all exports (nodeSetup, node, and project)
This implementation serves as a good reference for other files implementing scoped exports.
Also applies to: 68-68, 116-116, 136-137
packages/core-generators/src/generators/node/typescript/index.ts (2)
17-17: LGTM: Import of project scope.The addition of
projectScopealigns with the PR's objective to implement scoped exports.
144-144: LGTM: Provider exports now use project scope.The modification of exports to use
projectScopecorrectly implements the new scoped export pattern, replacing the previous hoisted/peer provider approach.Also applies to: 202-202
packages/fastify-generators/src/generators/pothos/pothos/index.ts (1)
67-69: LGTM: Consistent application of project scope across Pothos providers.The changes uniformly apply
projectScopeto all Pothos-related providers, maintaining consistency in the new scoped export pattern.Also applies to: 109-111, 152-152
packages/react-generators/src/generators/admin/admin-crud-edit/index.ts (1)
75-76: Verify if missing scope parameter is intentional.Other files in this PR use
projectScopein their export calls, but these exports don't specify any scope. Please verify if this is intentional or if they should also useprojectScopefor consistency.Run the following script to check if other admin CRUD providers use scopes in their exports:
✅ Verification successful
Missing scope parameter is intentional and follows the codebase pattern
UI component providers consistently omit scope parameters, while section-level providers use them. This architectural pattern separates scoped business logic from reusable UI components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if other admin CRUD providers use scopes in their exports # Test: Search for export calls in admin CRUD providers. Expect: Consistent usage of scopes. rg -A 5 'adminCrud.*Provider\.export' packages/react-generators/src/generators/admin/Length of output: 6449
packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (3)
42-42: LGTM: Introduction of section scope and required ID.The addition of
adminCrudSectionScopeand the requiredidfield enhances the granularity of provider resolution, aligning with the PR's objective to improve dependency management.Also applies to: 45-45
141-142: Verify if missing scope parameter is intentional.Similar to the previous file, these exports don't specify any scope. Please verify if this is intentional or if they should use
projectScopefor consistency.
189-192: LGTM: Section-scoped export with ID.The export correctly uses both
adminCrudSectionScopeandidparameters, implementing a more granular scoping mechanism for embedded forms.packages/react-generators/src/generators/apollo/react-apollo/index.ts (1)
8-8: LGTM: Import of projectScopeThe addition of
projectScopealigns with the PR's objective of implementing scoped exports for provider dependency resolution.packages/fastify-generators/src/generators/prisma/embedded-relation-transformer/index.ts (1)
46-46: LGTM: Schema property renameRenaming from
foreignCrudServiceReftoforeignModelNameimproves clarity by explicitly indicating the purpose of the field..changeset/soft-bottles-poke.md (1)
1-5: LGTM: Well-documented changesetThe changeset appropriately documents the dependency map refactoring with a patch version bump, indicating a backward-compatible implementation change.
packages/sync/package.json (2)
37-37: Consider adding type definitions for es-toolkit.Since TypeScript is used in the project, consider adding
@types/es-toolkitif available, or ensure the package includes built-in type definitions.
37-37: Verify if ramda can be removed.Since es-toolkit is being added to replace ramda functions, verify if ramda can be completely removed to avoid duplicate functionality.
Also applies to: 45-45
packages/project-builder-server/package.json (1)
40-43: Breaking Change: Generator packages moved to runtime dependencies.Moving these packages from devDependencies to dependencies is a breaking change that could affect downstream consumers. Please ensure this is intentional and documented in the changeset.
packages/fastify-generators/src/generators/core/app-module/index.ts (1)
4-4: LGTM: Proper implementation of scoped exports.The changes correctly implement the new scoping mechanism by:
- Importing the featureScope
- Using scoped export for the appModule provider
- Declaring the generator's scopes
Let's verify consistent implementation across other modules:
Also applies to: 32-32, 34-34
✅ Verification successful
Verified: Consistent scoped export implementation across modules
The scoping implementation is consistent across the codebase:
app-moduleusesfeatureScopeadmin-crud-sectionusesadminCrudSectionScope- Both follow the same pattern for scoped exports and scope declarations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for consistent usage of featureScope in other modules ast-grep --pattern 'export const $_ = createGeneratorWithChildren({ $$$ scopes: [$_], $$$ })' # Check for consistent usage of scoped exports ast-grep --pattern '$_.export($scope)'Length of output: 142
Script:
#!/bin/bash # Check featureScope imports rg "import.*featureScope" -l # Check generator configurations with scopes ast-grep --pattern 'createGeneratorWithChildren({ $$$ scopes: $$$ $$$ })' # Check export patterns rg "\.export\(.*scope" -lLength of output: 11687
packages/react-generators/src/generators/auth/auth-login-page/index.ts (3)
3-3: LGTM! Import of projectScope aligns with scoped exports refactoringThe addition of
projectScopeimport is consistent with the PR's objective of implementing scoped exports to replace hoisted/peer providers.
45-45: LGTM! Export now uses scoped provider patternThe change from direct provider export to
authLoginPageProvider.export(projectScope)aligns with the new scoped exports architecture.
45-46: Verify route prefix handling after reactLinkable removalThe removal of
reactLinkableexport suggests that the login route prefix functionality has been moved or is now handled differently. Let's verify this change:✅ Verification successful
Route prefix handling remains functional after reactLinkable removal
The login route prefix is properly handled through the directory structure and layout configuration. The path is correctly set as 'login' with the 'auth' layout key, maintaining the expected routing behavior.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any new implementations of login route prefix handling rg -g '!node_modules' -g '*.{ts,tsx}' "getRoutePrefix.*login" # Look for other potential route prefix implementations ast-grep --pattern 'export const $routeVar = $$$prefix$$$login$$$'Length of output: 132
Script:
#!/bin/bash # Search for login route patterns and configurations rg -g '!node_modules' -g '*.{ts,tsx}' -i "route.*login|path.*login" -A 2 # Search for auth route handling rg -g '!node_modules' -g '*.{ts,tsx}' "authRoutes|AUTH_ROUTES" -A 2 # Look for route prefix handling patterns ast-grep --pattern 'const $_ = { $$$ route: $$$, $$$ }' # Search for any login-related exports ast-grep --pattern 'export const $_ = { $$$ login: $$$, $$$ }'Length of output: 2074
| mergeWith(newObj, obj, (obj, src, key) => { | ||
| if (obj !== undefined && src !== undefined) { | ||
| throw new Error(`Duplicate key (${key}) detected`); | ||
| } | ||
| }); |
There was a problem hiding this comment.
Ensure customizer function in mergeWith handles all cases correctly
In mergeAllWithoutDuplicates, the customizer function passed to mergeWith does not return a value when there is no duplicate key. According to mergeWith's expected behavior, the customizer should return undefined to proceed with the default merging. Consider explicitly returning undefined to avoid any unexpected behavior.
Apply this diff to fix the issue:
mergeWith(newObj, obj, (objValue, srcValue, key) => {
if (objValue !== undefined && srcValue !== undefined) {
throw new Error(`Duplicate key (${key}) detected`);
+ } else {
+ return undefined; // Proceed with default merging
}
});📝 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.
| mergeWith(newObj, obj, (obj, src, key) => { | |
| if (obj !== undefined && src !== undefined) { | |
| throw new Error(`Duplicate key (${key}) detected`); | |
| } | |
| }); | |
| mergeWith(newObj, obj, (objValue, srcValue, key) => { | |
| if (objValue !== undefined && srcValue !== undefined) { | |
| throw new Error(`Duplicate key (${key}) detected`); | |
| } else { | |
| return undefined; // Proceed with default merging | |
| } | |
| }); |
| @@ -1,2 +1,3 @@ | |||
| export type * from './import-mapper.js'; | |||
There was a problem hiding this comment.
Fix invalid syntax in export statement
The statement export type * from './import-mapper.js'; is invalid TypeScript syntax. To re-export all types, you should specify the types explicitly or use the correct syntax. The export type syntax requires specifying the types to export.
Apply this diff to fix the syntax error:
-export type * from './import-mapper.js';
+export * from './import-mapper.js';If you intend to only export types and avoid exporting values, list the specific types:
export type { ImportMapper } from './import-mapper.js';| }, | ||
| exports: { | ||
| adminCrudForeignDisplay: adminCrudForeignDisplayProvider, | ||
| adminCrudForeignDisplay: adminCrudForeignDisplayProvider.export(), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using projectScope for consistent provider resolution
While the change implements the export method pattern, it doesn't use projectScope like other generators (e.g., react-auth0, react-datadog). Consider updating this to maintain consistency:
- adminCrudForeignDisplay: adminCrudForeignDisplayProvider.export(),
+ adminCrudForeignDisplay: adminCrudForeignDisplayProvider.export(projectScope),Don't forget to add the import:
+import { projectScope } from '@halfdomelabs/core-generators';Committable suggestion skipped: line range outside the PR's diff.
| }, | ||
| exports: { | ||
| pothosEnumsFile: pothosEnumsFileProvider, | ||
| pothosEnumsFile: pothosEnumsFileProvider.export(), |
There was a problem hiding this comment.
Add projectScope parameter for consistency.
Other files in this PR are using export(projectScope), but this file only calls export(). For consistency with the new scoped exports pattern, consider adding the projectScope parameter.
Apply this diff:
- pothosEnumsFile: pothosEnumsFileProvider.export(),
+ pothosEnumsFile: pothosEnumsFileProvider.export(projectScope),Committable suggestion skipped: line range outside the PR's diff.
| import { projectScope } from '@src/providers/scopes.js'; | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Standardize the import source for projectScope.
While the scoped export implementation is correct, the import source for projectScope differs from other files:
- Other files import from
@halfdomelabs/core-generators - This file imports from
@src/providers/scopes.js
Consider standardizing the import source across all files.
-import { projectScope } from '@src/providers/scopes.js';
+import { projectScope } from '@halfdomelabs/core-generators';Also applies to: 63-63
| }, | ||
| exports: { | ||
| pothosTypes: pothosTypesFileProvider, | ||
| pothosTypes: pothosTypesFileProvider.export(), |
There was a problem hiding this comment.
Inconsistent implementation of scoped exports
Unlike other files in this PR, this export doesn't utilize projectScope. Consider updating to pothosTypesFileProvider.export(projectScope) for consistency with other changes.
Apply this diff to maintain consistency:
- pothosTypes: pothosTypesFileProvider.export(),
+ pothosTypes: pothosTypesFileProvider.export(projectScope),Committable suggestion skipped: line range outside the PR's diff.
| reactRoutes: reactRoutesProvider.export(), | ||
| reactRoutesReadOnly: reactRoutesReadOnlyProvider.export(), |
There was a problem hiding this comment.
Add projectScope parameter to export() calls for consistency.
The export() calls should include the projectScope parameter to maintain consistency with other files in this PR. This ensures proper scoping of the exports.
Apply this diff:
- reactRoutes: reactRoutesProvider.export(),
- reactRoutesReadOnly: reactRoutesReadOnlyProvider.export(),
+ reactRoutes: reactRoutesProvider.export(projectScope),
+ reactRoutesReadOnly: reactRoutesReadOnlyProvider.export(projectScope),Committable suggestion skipped: line range outside the PR's diff.
| }, | ||
| exports: { | ||
| adminCrudColumnContainer: adminCrudColumnContainerProvider, | ||
| adminCrudColumnContainer: adminCrudColumnContainerProvider.export(), |
There was a problem hiding this comment.
Add missing projectScope parameter to export.
The export should include the projectScope parameter to maintain consistency with other files in the codebase.
Apply this diff to add the missing parameter:
- adminCrudColumnContainer: adminCrudColumnContainerProvider.export(),
+ adminCrudColumnContainer: adminCrudColumnContainerProvider.export(projectScope),Committable suggestion skipped: line range outside the PR's diff.
kingston
deleted the
kingston/eng-517-implement-scoped-exports-to-replace-hoisted-peer-providers
branch
1 participant
Summary by CodeRabbit
Based on the comprehensive summary of changes, here are the high-level release notes for end-users:
Release Notes
New Features
Dependency Management
Generator Improvements
Breaking Changes
peerProviderandhoistedProvidersfrom generator configurationsPerformance
This release focuses on improving the flexibility and clarity of dependency management across the project generation ecosystem.