feat: Introduce output provider concept #473
Conversation
- no actual implementation yet, just getting the types in place
🦋 Changeset detectedLatest commit: 3856e84 The changes in this PR will be included in the next version bump. 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 |
WalkthroughThis pull request introduces a new output provider concept that replaces task dependencies across multiple generator packages. The changes include the integration of a new setup task via a dedicated Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant GR as Generator Runner
participant TT as Task (Setup/Build)
participant OP as Output Provider
U->>GR: Trigger generator execution
GR->>TT: Invoke task run method
TT->>OP: Generate outputs via createSetupTask / createOutputProviderType
OP-->>TT: Return configured output object
TT-->>GR: Return outputs and dependencies
GR->>GR: Validate outputs and resolve dependencies
GR->>U: Complete execution with generated output
🪧 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: 2
🧹 Nitpick comments (10)
packages/sync/src/utils/create-generator.unit.test.ts (1)
120-122: Well-implemented callback pattern for task outputsThe modification from returning a value to using a callback pattern (
addTaskOutput) aligns well with the introduced output provider concept. This is a good architectural shift that decouples how tasks produce outputs from how those outputs are consumed.For better clarity and type safety in the test on line 140, consider replacing the empty object cast to
GeneratorTaskOutputBuilderwith a properly mocked object:- await build?.({} as unknown as GeneratorTaskOutputBuilder); + await build?.({} as unknown as GeneratorTaskOutputBuilder, (output) => { + // The output handling happens in the callback + });packages/sync/src/runner/generator-runner.unit.test.ts (1)
205-253: Consider using interfaces instead of type assertionsThe test correctly validates output provider functionality, but uses type assertions which could be improved.
Instead of using type assertions like
(deps.outputDep as { generate: () => void }), consider defining proper interfaces:+ interface OutputProvider { + generate: () => void; + } it('handles output providers correctly', async () => { const outputProviderType = createOutputProviderType<{ generate: () => void; }>('output-provider'); const outputProvider = { generate: vi.fn() }; // ... - (deps.outputDep as { generate: () => void }).generate(); + (deps.outputDep as OutputProvider).generate(); // ... });packages/sync/src/runner/dependency-sort.ts (1)
40-47: Strong improvement to dependency management for output providers.The new condition properly handles output provider dependencies by ensuring the dependent task must be built before the current task can initialize. This directly supports the PR's objective of introducing output providers as an alternative to task dependencies.
Consider adding a comment explaining the distinction between output dependencies and regular dependencies for future maintainability:
// check if the dependency is to an output provider and if so, // we need to wait until the dependent task has been built before // we can build the current task + // Output providers require a stronger dependency - the dependent task's + // build phase must complete before the current task can even initialize if (dependent.options?.isOutput) { return [[dependentBuild, entryInit] as [string, string]]; }packages/sync/src/generators/build-generator-entry.unit.test.ts (1)
1-181: Test suite needs expansion for output providers.While the tests have been updated to reflect the new structure, I don't see explicit tests for the new output provider functionality introduced in this PR.
Consider adding a new test case that validates the behavior of output providers, ensuring they're properly handled by the
buildGeneratorEntryfunction. For example:it('handles output providers correctly', async () => { // Setup test environment... const outputProvidingTask = { name: 'output-provider-task', dependencies: {}, exports: {}, taskDependencies: [], run: () => ({ providers: {}, outputs: { someOutput: { /* output provider details */ } }, build: () => ({}) }), }; const bundle = buildTestGeneratorBundle({ name: 'test-generator', directory: '/test', tasks: [outputProvidingTask], }); const entry = await buildGeneratorEntry(bundle, { logger }); // Verify the output provider is correctly included in the entry expect(entry.tasks[0]).toHaveProperty('outputs.someOutput'); });packages/sync/src/runner/dependency-map.ts (3)
40-40: Comment clarity.This line merely documents the process of adding scoped exports and outputs. Make sure the comment stays updated if logic evolves.
75-78: Error handling approach is consistent.Throwing an error for missing
generatorEntryis sensible. It ensures no silent misconfiguration. Consider adding guidance or context in the error to help developers troubleshoot faster.
180-183: StoringisReadOnlyandisOutputas undefined vs false.Conditions map booleans to either
trueorundefined. This can simplify usage, but watch out if code depends on an explicitfalsevalue. Overall, it’s consistent with optional properties.packages/sync/src/providers/providers.ts (1)
106-109: Slight naming nitpick.
parentScopeOnly()is descriptive, but you may consider a name likeresolveFromParent()orskipLocalScope()for clarity.packages/sync/src/generators/generators.ts (2)
61-70: Interface for provider exports.Defining
GeneratorTaskResultProvidersto accept an optionalExportMaptype is a good step. Just ensure that any consumer properly checks forundefinedwhen usingproviders.
72-83: Potential improvement for error handling in build.
GeneratorTaskResultBuildersWithOutputspermits both synchronous and asynchronous returns. Consider clarifying how errors should be bubbled up or handled in the promise to maintain consistency across tasks.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
📒 Files selected for processing (55)
.changeset/bright-seals-rescue.md(1 hunks).cursor/rules/writing-vitest-tests.mdc(1 hunks)packages/core-generators/src/generators/docker/docker-compose/index.ts(0 hunks)packages/core-generators/src/generators/node/node/index.ts(2 hunks)packages/core-generators/src/generators/node/typescript/index.ts(5 hunks)packages/fastify-generators/src/generators/auth/auth-context/index.ts(4 hunks)packages/fastify-generators/src/generators/auth/auth-plugin/index.ts(0 hunks)packages/fastify-generators/src/generators/auth/auth-roles/index.ts(3 hunks)packages/fastify-generators/src/generators/auth/auth/index.ts(2 hunks)packages/fastify-generators/src/generators/auth0/auth0-module/index.ts(4 hunks)packages/fastify-generators/src/generators/core/app-module/index.ts(1 hunks)packages/fastify-generators/src/generators/core/fastify-server/index.ts(2 hunks)packages/fastify-generators/src/generators/core/fastify/index.ts(6 hunks)packages/fastify-generators/src/generators/core/fastify/setup-fastify-typescript.ts(1 hunks)packages/fastify-generators/src/generators/core/readme/index.ts(0 hunks)packages/fastify-generators/src/generators/core/request-service-context/index.ts(4 hunks)packages/fastify-generators/src/generators/core/root-module/index.ts(6 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/pothos/pothos-sentry/index.ts(2 hunks)packages/fastify-generators/src/generators/pothos/pothos/index.ts(11 hunks)packages/fastify-generators/src/generators/prisma/prisma-crud-create/index.ts(0 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(4 hunks)packages/fastify-generators/src/generators/prisma/prisma-crud-update/index.ts(0 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/index.ts(6 hunks)packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts(4 hunks)packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts(2 hunks)packages/react-generators/src/generators/core/react-routes/index.ts(1 hunks)packages/react-generators/src/generators/core/react-typescript/index.ts(2 hunks)packages/react-generators/src/generators/core/react/index.ts(1 hunks)packages/sync/src/generators/build-generator-entry.ts(2 hunks)packages/sync/src/generators/build-generator-entry.unit.test.ts(2 hunks)packages/sync/src/generators/generators.ts(3 hunks)packages/sync/src/generators/generators.unit.test.ts(1 hunks)packages/sync/src/providers/providers.ts(10 hunks)packages/sync/src/runner/dependency-map.ts(8 hunks)packages/sync/src/runner/dependency-map.unit.test.ts(3 hunks)packages/sync/src/runner/dependency-sort.ts(1 hunks)packages/sync/src/runner/dependency-sort.unit.test.ts(2 hunks)packages/sync/src/runner/generator-runner.ts(2 hunks)packages/sync/src/runner/generator-runner.unit.test.ts(5 hunks)packages/sync/src/runner/tests/factories.test-helper.ts(1 hunks)packages/sync/src/utils/create-generator-types.ts(8 hunks)packages/sync/src/utils/create-generator.ts(3 hunks)packages/sync/src/utils/create-generator.unit.test.ts(1 hunks)packages/sync/src/utils/create-setup-task.ts(1 hunks)packages/sync/src/utils/index.ts(1 hunks)packages/tools/eslint-configs/typescript.js(1 hunks)packages/utils/src/field-map/field-map.ts(1 hunks)packages/utils/src/field-map/field-map.unit.test.ts(1 hunks)packages/utils/src/field-map/index.ts(1 hunks)packages/utils/src/index.ts(1 hunks)
💤 Files with no reviewable changes (5)
- packages/fastify-generators/src/generators/core/readme/index.ts
- packages/fastify-generators/src/generators/prisma/prisma-crud-create/index.ts
- packages/fastify-generators/src/generators/prisma/prisma-crud-update/index.ts
- packages/fastify-generators/src/generators/auth/auth-plugin/index.ts
- packages/core-generators/src/generators/docker/docker-compose/index.ts
🧰 Additional context used
🧬 Code Definitions (22)
packages/sync/src/generators/build-generator-entry.ts (1)
packages/sync/src/generators/generators.ts (1)
ProviderExportMap(32-34)
packages/fastify-generators/src/generators/core/app-module/index.ts (1)
packages/fastify-generators/src/generators/core/root-module/index.ts (1)
appModuleProvider(64-65)
packages/fastify-generators/src/generators/core/fastify-server/index.ts (2)
packages/fastify-generators/src/generators/core/root-module/index.ts (2)
rootModuleConfigProvider(43-43)rootModuleImportProvider(50-55)packages/core-generators/src/writers/typescript/code-entries.ts (1)
TypescriptCodeUtils(336-597)
packages/sync/src/generators/generators.unit.test.ts (2)
packages/sync/src/generators/generators.ts (5)
ProviderExportMap(32-34)ProviderDependencyMap(39-41)GeneratorTask(121-161)InferExportProviderMap(46-50)InferDependencyProviderMap(55-59)packages/sync/src/providers/providers.ts (1)
createProviderType(164-225)
packages/fastify-generators/src/generators/auth/auth-roles/index.ts (1)
packages/fastify-generators/src/generators/auth/auth/index.ts (1)
authConfigProvider(29-29)
packages/sync/src/utils/create-generator.ts (3)
packages/sync/src/utils/create-generator-types.ts (2)
SimpleGeneratorTaskConfig(73-107)GeneratorTaskBuilder(182-209)packages/sync/src/generators/generators.ts (1)
GeneratorTask(121-161)packages/sync/src/providers/providers.ts (1)
Provider(11-11)
packages/fastify-generators/src/generators/auth/auth-context/index.ts (1)
packages/fastify-generators/src/generators/auth/auth/index.ts (1)
authConfigProvider(29-29)
packages/sync/src/utils/create-setup-task.ts (3)
packages/utils/src/field-map/field-map.ts (4)
FieldMapSchema(152-152)FieldMapValues(155-157)FieldMapSchemaBuilder(165-212)createFieldMap(227-246)packages/sync/src/utils/create-generator-types.ts (1)
SimpleGeneratorTaskConfig(73-107)packages/sync/src/providers/providers.ts (3)
ProviderType(17-45)createProviderType(164-225)createOutputProviderType(234-239)
packages/fastify-generators/src/generators/auth0/auth0-module/index.ts (1)
packages/fastify-generators/src/generators/auth/auth/index.ts (1)
authConfigProvider(29-29)
packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (3)
packages/utils/src/field-map/field-map.ts (3)
createFieldMapSchemaBuilder(214-218)FieldMapValues(155-157)createFieldMap(227-246)packages/sync/src/providers/providers.ts (2)
createProviderType(164-225)createOutputProviderType(234-239)packages/sync/src/utils/create-generator.ts (1)
createGenerator(84-162)
packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (8)
packages/sync/src/providers/providers.ts (1)
createOutputProviderType(234-239)packages/react-generators/src/generators/admin/admin-crud-edit/index.ts (1)
adminCrudEditProvider(43-44)packages/react-generators/src/generators/admin/admin-components/index.ts (1)
adminComponentsProvider(19-20)packages/react-generators/src/generators/core/react-components/index.ts (1)
reactComponentsProvider(68-69)packages/react-generators/src/generators/core/react-error/index.ts (1)
reactErrorProvider(26-27)packages/core-generators/src/generators/node/typescript/index.ts (1)
typescriptProvider(107-108)packages/react-generators/src/generators/admin/admin-crud-section/index.ts (1)
adminCrudSectionScope(15-18)packages/react-generators/src/writers/graphql/index.ts (1)
GraphQLField(34-34)
packages/react-generators/src/generators/core/react-typescript/index.ts (2)
packages/core-generators/src/generators/node/typescript/index.ts (1)
typescriptSetupProvider(165-165)packages/core-generators/src/generators/node/eslint/index.ts (1)
eslintProvider(27-27)
packages/fastify-generators/src/generators/core/fastify/setup-fastify-typescript.ts (1)
packages/core-generators/src/generators/node/typescript/index.ts (1)
TypescriptSetupProvider(171-173)
packages/core-generators/src/generators/node/typescript/index.ts (5)
packages/core-generators/src/constants/core-packages.ts (1)
CORE_PACKAGES(1-27)packages/sync/src/providers/providers.ts (1)
InferProviderType(47-47)packages/sync/src/utils/create-generator.ts (1)
createGenerator(84-162)packages/core-generators/src/generators/node/node/index.ts (1)
nodeProvider(44-44)packages/core-generators/src/writers/typescript/imports.ts (1)
PathMapEntry(36-39)
packages/fastify-generators/src/generators/core/fastify/index.ts (3)
packages/sync/src/providers/providers.ts (1)
createOutputProviderType(234-239)packages/core-generators/src/generators/node/typescript/index.ts (1)
typescriptSetupProvider(165-165)packages/fastify-generators/src/generators/core/fastify/setup-fastify-typescript.ts (1)
setupFastifyTypescript(8-41)
packages/fastify-generators/src/generators/pothos/pothos-sentry/index.ts (3)
packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (1)
yogaPluginConfigProvider(71-72)packages/core-generators/src/generators/node/typescript/index.ts (1)
typescriptProvider(107-108)packages/core-generators/src/generators/node/node/index.ts (1)
nodeProvider(44-44)
packages/fastify-generators/src/generators/pothos/pothos/index.ts (3)
packages/sync/src/providers/providers.ts (1)
createOutputProviderType(234-239)packages/fastify-generators/src/writers/pothos/options.ts (1)
PothosTypeReferenceContainer(46-142)packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (1)
yogaPluginConfigProvider(71-72)
packages/sync/src/runner/dependency-map.ts (1)
packages/sync/src/providers/providers.ts (1)
ProviderDependencyOptions(49-75)
packages/sync/src/generators/generators.ts (2)
packages/sync/src/providers/providers.ts (1)
Provider(11-11)packages/sync/src/output/generator-task-output.ts (1)
GeneratorTaskOutputBuilder(105-224)
packages/sync/src/utils/create-generator-types.ts (3)
packages/sync/src/providers/providers.ts (1)
Provider(11-11)packages/sync/src/output/generator-task-output.ts (1)
GeneratorTaskOutputBuilder(105-224)packages/sync/src/generators/generators.ts (4)
ProviderExportMap(32-34)ProviderDependencyMap(39-41)InferDependencyProviderMap(55-59)InferExportProviderMap(46-50)
packages/utils/src/field-map/field-map.unit.test.ts (1)
packages/utils/src/field-map/field-map.ts (1)
createFieldMap(227-246)
packages/sync/src/runner/dependency-map.unit.test.ts (3)
packages/sync/src/providers/providers.ts (1)
createProviderType(164-225)packages/sync/src/runner/tests/factories.test-helper.ts (2)
buildTestGeneratorEntry(50-75)buildTestGeneratorTaskEntry(26-48)packages/sync/src/runner/dependency-map.ts (1)
resolveTaskDependencies(253-266)
🔇 Additional comments (214)
packages/tools/eslint-configs/typescript.js (1)
216-220: Good enhancement to enable typechecking in Vitest!Adding typechecking for Vitest tests will help catch type errors during testing, improving overall code quality and preventing potential runtime issues. This aligns well with the PR's focus on enhancing generator configurations.
packages/sync/src/runner/generator-runner.unit.test.ts (5)
15-18: Import changes reflect new output provider conceptThe addition of
createOutputProviderTypeimport aligns well with the PR objective of introducing output providers to replace task dependencies.
31-39: Return type expansion provides necessary flexibilityThe expanded return type for the
buildfunction now supports void, Record<string, unknown>, or Promises of either, which is essential for supporting output providers that may return different types of data.
52-53: Output map handling is properly implementedThe changes correctly initialize an empty
outputMapwhen not provided and pass it to the task object, ensuring proper integration of output providers into the generator entry structure.Also applies to: 63-64, 69-70
255-302: Test for multiple exports and dependencies looks robustThis test effectively validates that multiple providers can be exported and consumed correctly, which is an important scenario for the output provider concept.
304-322: Good error handling testThe test for handling missing providers is important for ensuring robust dependency resolution. It correctly verifies that an appropriate error is thrown when a required provider is not exported.
.cursor/rules/writing-vitest-tests.mdc (1)
6-6: Documentation clarification looks good.This clarification specifies that the
.jsextension requirement applies specifically to import statements rather than all files in the project. This is an important distinction that helps developers understand when this requirement applies.packages/utils/src/field-map/index.ts (1)
1-2: Proper module export structure.This barrel file correctly exports all entities from the field-map.js module, making them accessible through a single import. This follows good module organization practices.
packages/sync/src/utils/index.ts (1)
3-3: New setup task utility export looks good.This export makes the
create-setup-task.jsmodule available through the utils index, which aligns with the PR objective of introducing output providers. ThecreateSetupTaskfunction likely plays a key role in eliminating task dependencies.packages/utils/src/index.ts (1)
3-3: Good integration of the new field-map module.The new export makes the field-map functionality available through the main utils index. This is important for enabling the output provider concept throughout the codebase. The field-map module appears to provide type-safe container management that will support the new provider architecture.
packages/fastify-generators/src/generators/prisma/prisma-enum/index.ts (1)
27-27: Simplified return value in alignment with output provider patternThis change removes the empty
providersobject from the return statement, aligning with the PR's objective of introducing output providers to replace task dependencies. The simplified return is appropriate since no actual provider data was being returned.packages/fastify-generators/src/generators/core/app-module/index.ts (1)
30-30:Details
✅ Verification successful
Modified dependency resolution to use
parentScopeOnlyThe change restricts the
appModuledependency resolution to only look in the parent scope, which is a more precise specification of the dependency's context. This modification aligns with the PR's objective of refining provider handling.
🏁 Script executed:
#!/bin/bash # Check for other usages of parentScopeOnly() to verify consistency rg -A 2 "parentScopeOnly()" --type tsLength of output: 1745
Verified: Consistent Dependency Resolution with
parentScopeOnly()The update to use
parentScopeOnly()in theappModuledependency resolution is consistent with its usage throughout the repository. Our verification shows that similar patterns are applied in several files, including:
- Fastify Generators:
packages/fastify-generators/src/generators/core/app-module/index.ts- React Generators:
packages/react-generators/src/generators/core/react-routes/index.ts- Sync Modules: Test files and provider definitions in
packages/sync/src/runner/andpackages/sync/src/providers/These findings confirm that the modification correctly refines the dependency resolution to target only the parent scope, aligning with the PR's objective.
packages/react-generators/src/generators/core/react/index.ts (1)
199-199:Details
✅ Verification successful
Updated ESM configuration API to use output provider pattern
The change replaces the direct
setIsEsmmethod call with a property-based approach that includes the generator name for better context tracking. This is in line with the PR objective of introducing output providers.
🏁 Script executed:
#!/bin/bash # Check for other usages of isEsm to confirm consistency of the new pattern rg "isEsm\.set\(" --type ts # Also check if there are any remaining uses of the old pattern that might need updating rg "setIsEsm\(" --type tsLength of output: 308
ESM configuration API update verified and approved.
The new property-based approach (usingnodeSetup.isEsm.set(...)with the generator name) is applied consistently in both the React generator and the Fastify generator. The search confirmed that there are no remaining instances of the oldsetIsEsmAPI.
- React Generator:
- File:
packages/react-generators/src/generators/core/react/index.ts- Code:
nodeSetup.isEsm.set(true, taskBuilder.generatorName);- Fastify Generator:
- File:
packages/fastify-generators/src/generators/core/fastify/index.ts- Code:
nodeSetup.isEsm.set(false, taskBuilder.generatorName);The changes meet the PR objectives.
packages/fastify-generators/src/generators/prisma/prisma-crud-delete/index.ts (1)
144-144: Simplified return statement by removing empty providers objectThis change removes the unused
prismaDeleteMethodprovider from the return statement, consistent with the PR's goal of refactoring the provider pattern. The empty object return is sufficient since no data needs to be provided back to the caller.packages/sync/src/generators/build-generator-entry.ts (2)
29-32: Adds theoutputsproperty to the GeneratorTaskEntry interface.This is a good addition aligned with the PR objective of introducing output providers. It extends the task entry data structure with the same type as
exports(ProviderExportMap), providing a clear separation between exported providers and output providers.
101-101: Correctly initializes theoutputsproperty for each task entry.The implementation appropriately adds the outputs property to the task entry object, defaulting to an empty object if task.outputs is undefined. This approach is consistent with how other properties like dependencies and exports are handled.
.changeset/bright-seals-rescue.md (1)
1-10: Properly documents changeset for the output providers feature.The changeset correctly identifies all affected packages that need patch updates as a result of introducing the output providers concept. The description clearly states the purpose of the change: replacing task dependencies with output providers.
packages/react-generators/src/generators/core/react-routes/index.ts (1)
35-35: Added scope restriction to reactRoutes dependency.The addition of
.parentScopeOnly()to the reactRoutes dependency ensures that the dependency is resolved only from the parent scope, which is a good practice when transitioning to output providers. This helps in controlling the dependency resolution flow.packages/fastify-generators/src/generators/prisma/prisma-field/index.ts (1)
82-82: Removes unnecessary providers object from return value.This change aligns with the transition to output providers. The empty providers object is no longer needed since the task has already done its work of adding the field to the prisma model. Simplifying the return value makes the code cleaner.
packages/sync/src/runner/tests/factories.test-helper.ts (2)
34-34: Added support for output providers in test helper functionThe
outputs: {}property has been added to the return type ofbuildTestGeneratorTaskEntryto support the new output provider concept being introduced in this PR.
41-41: Added outputs field to task object structureThe addition of
outputs: {}to the task object structure ensures consistency with the real task implementations that will now support output providers.packages/fastify-generators/src/generators/pothos/pothos-sentry/index.ts (4)
13-13: Updated import to use the new provider nameThe import has been changed from
yogaPluginSetupProvidertoyogaPluginConfigProvider, reflecting the shift toward more specific provider naming and responsibilities.
22-23: Updated dependency to use the new config providerChanged from
yogaPluginSetup: yogaPluginSetupProvidertoyogaPluginConfig: yogaPluginConfigProviderto match the renamed provider.
27-27: Updated function parameter to match the new provider nameThe function parameter has been updated from
yogaPluginSetuptoyogaPluginConfigto maintain consistency with the provider renaming.
32-36:Details
❓ Verification inconclusive
Simplified API for plugin registration
The code has been refactored from using
yogaPluginSetup.getConfig().appendUnique(...)to directly pushing toyogaPluginConfig.envelopPlugins.push(...), which simplifies the API by removing one level of method chaining.
🏁 Script executed:
#!/bin/bash # Check if all usages of the old yogaPluginSetup API have been updated echo "Checking for remaining usages of yogaPluginSetup.getConfig().appendUnique..." rg -l "yogaPluginSetup.getConfig\(\).appendUnique" --type tsLength of output: 225
Simplified API for Plugin Registration – Manual Verification Recommended
- The change in file
packages/fastify-generators/src/generators/pothos/pothos-sentry/index.ts(lines 32-36) now directly pushes the plugin intoyogaPluginConfig.envelopPluginsinstead of usingyogaPluginSetup.getConfig().appendUnique(...).- A repository-wide search for
"yogaPluginSetup.getConfig().appendUnique"produced no results, which suggests that all usages of the old API have been removed.- However, because the verification output was minimal, please perform a manual verification to ensure no residual references to the old API remain.
Code snippet (final state):
yogaPluginConfig.envelopPlugins.push( new TypescriptCodeExpression(`useSentry()`, [ `import { useSentry } from '${pluginImport}'`, ]), );packages/sync/src/runner/generator-runner.ts (2)
40-40: Added outputs to destructuring assignmentThe destructuring assignment now includes
outputsfromtaskEntriesById[taskId], allowing the function to access the outputs associated with each task.
105-129: Implemented output provider validation and mappingThis new block implements the core functionality of the output provider concept:
- It checks if a task's build function produces output providers
- Validates that all expected output providers are present
- Updates the provider map to associate outputs with their corresponding providers
This is a critical part of the new output provider architecture that eliminates the need for task dependencies as mentioned in the PR objectives.
packages/fastify-generators/src/generators/core/fastify-server/index.ts (3)
24-27: Split root module provider into config and import providersThe previous
rootModuleProviderhas been split into more specialized providers:
rootModuleConfigProvider: For configuring the root modulerootModuleImportProvider: For importing/accessing the root moduleThis change improves separation of concerns and aligns with the output provider concept being introduced.
59-74: Added new task for root module configurationA new task
root-module-confighas been added that configures the plugins field in the root module. This task uses the newrootModuleConfigProviderto set up the module field.This separation allows for more focused tasks with clearer responsibilities, with this task handling configuration aspects while other tasks handle importing/using the module.
81-81: Updated dependency to use the new import providerThe dependency has been updated from
rootModuleProvidertorootModuleImportProviderto match the new provider structure that separates configuration from import functionality.packages/fastify-generators/src/generators/auth/auth-context/index.ts (4)
24-24: Updated authentication provider naming.The import has been changed from
authSetupProvidertoauthConfigProvider, aligning with the refactoring approach for provider naming across the codebase.
42-42: Updated dependency name.The dependency has been renamed from
authSetuptoauthConfigto maintain consistency with the import change.
54-54: Updated parameter name.The parameter has been renamed from
authSetuptoauthConfigto maintain consistency with the dependency change.
87-93:Details
❓ Verification inconclusive
Improved API structure for authentication configuration.
The configuration approach has been changed from method-based (
authSetup.getConfig().set()) to a more direct property-based approach (authConfig.contextUtilsImport.set()). Also added the module identifier as a second parameter.Verify this pattern is consistently applied across all authentication configuration uses:
🏁 Script executed:
#!/bin/bash # Check if all instances of authSetup have been refactored to authConfig rg "authSetup" --type typescript --glob "packages/fastify-generators/**" # Check if the new pattern with module identifier is used consistently rg "authConfig\.[a-zA-Z]+\.set\([^,]+,[^)]+\)" --type typescript --glob "packages/fastify-generators/**"Length of output: 249
Action Required: Re-verify API Consistency Across Authentication Configuration
The authentication configuration update—migrating from the method-based pattern (
authSetup.getConfig().set()) to a direct property-based approach (authConfig.contextUtilsImport.set()) with an added module identifier—appears sound based on the code snippet. However, the initial automated checks returned errors due to the use of an unrecognized file type flag for TypeScript. Please run the updated verification commands below to ensure consistency across the codebase:
Verify no lingering references to the old API:
rg -t ts "authSetup" packages/fastify-generators/Confirm that the new pattern using a module identifier is applied consistently:
rg -t ts "authConfig\.[a-zA-Z]+\.set\([^,]+,\s*['\"][^'\"]+['\"]\)" packages/fastify-generators/Once these commands run without unexpected output, we can confidently conclude that the improved pattern has been uniformly applied across all authentication configuration instances.
packages/fastify-generators/src/generators/auth0/auth0-module/index.ts (4)
20-20: Updated authentication provider import.The import has been changed from
authSetupProvidertoauthConfigProvider, consistent with the changes in other files.
51-51: Updated dependency name.The dependency has been renamed from
authSetuptoauthConfigto maintain consistency with the import change.
66-66: Updated parameter name.The parameter has been renamed from
authSetuptoauthConfigto maintain consistency with the dependency change.
99-105: Improved API structure for user session service import configuration.The approach has been changed from method-based (
authSetup.getConfig().set()) to a more direct property-based approach (authConfig.userSessionServiceImport.set()). Also added the module identifier 'auth0/auth0-module' as a second parameter to provide context.packages/sync/src/generators/build-generator-entry.unit.test.ts (2)
50-53: Enhanced task return structure in tests.The test has been updated to reflect the new output provider model, now properly returning both
providersand abuildfunction from the task's run method.
99-102: Enhanced task return structure in tests.Similar to the other task, this test has been updated to reflect the new output provider model by returning both
providersand abuildfunction.packages/core-generators/src/generators/node/node/index.ts (4)
4-8: New utility import for improved setup task creationThe addition of
createSetupTaskfrom '@halfdomelabs/sync' aligns with the PR's objective of introducing output providers to eliminate the need for task dependencies.
54-60: Effective transition to output provider modelThe implementation of
createSetupTaskis clean and well-structured. This approach:
- Creates a setup task with a boolean property
isEsm- Returns a tuple with the task, provider, and output provider
- Properly scopes the configuration to the project
This is a good implementation of the output provider concept described in the PR objectives.
70-76: Task dependency replaced with output providerThe setup task is now properly added to the task builder, and the main task effectively uses the output provider as a dependency. This implementation correctly follows the new pattern of using output providers instead of direct task dependencies.
81-81: Simplified parameter destructuringThe run method now elegantly destructures the
isEsmproperty directly from the setup object, making the code more concise and easier to follow.packages/fastify-generators/src/generators/auth/auth-roles/index.ts (4)
15-15: Provider renamed to reflect its purposeRenaming from
authSetupProvidertoauthConfigProviderimproves clarity by better describing its role as a configuration provider rather than a setup provider.
47-47: Dependency naming updated for consistencyThe dependency name has been updated from
authSetuptoauthConfigto maintain consistency with the import change, ensuring the code remains coherent.
52-52: Run parameter updated to match dependencyThe run parameter has been appropriately updated to use
authConfiginstead ofauthSetup, maintaining consistency throughout the task definition.
78-78: Improved configuration APIThe method for setting auth roles import has been changed from a nested method call
authSetup.getConfig().set(...)to a more direct property accessauthConfig.authRolesImport.set(...). This change:
- Makes the code more readable
- Provides better property access patterns
- Includes the source identifier 'auth/auth-roles' for better traceability
This is a good example of the streamlined workflow mentioned in the PR objectives.
packages/fastify-generators/src/generators/core/service-context/index.ts (5)
15-15: New output provider type utility importedThe addition of
createOutputProviderTypefrom '@halfdomelabs/sync' supports the PR's objective of introducing output providers to replace task dependencies.
49-49: Provider type updated to output providerChanging
serviceContextProviderto usecreateOutputProviderTypeinstead ofcreateProviderTypeis a key implementation of the output provider concept. This change supports the goal of eliminating task dependencies as mentioned in the PR objectives.
56-58: Task naming simplifiedRenaming the task from 'setup' to 'main' simplifies the task structure and fits well with the new output provider pattern.
64-66: Output mechanism properly configuredThe addition of the
outputsproperty to export theserviceContextProvideris a key aspect of implementing the output provider pattern. This allows other tasks to consume the service context without creating direct dependencies.
179-189: Return structure improved for output providerThe return statement has been effectively updated to directly return a
serviceContextobject with all necessary methods. This structure is cleaner and more aligned with the output provider pattern:
- Provides getImportMap, getContextPath, and getServiceContextType methods
- Makes the service context type available via TypescriptCodeUtils.createExpression
- Properly references the context import path
This implementation follows good practices for structuring output providers.
packages/react-generators/src/generators/core/react-typescript/index.ts (4)
3-3: Provider renamed to reflect its purposeRenaming from
typescriptConfigProvidertotypescriptSetupProviderimproves clarity by better describing its role in setting up TypeScript rather than just configuring it.
18-19: Dependency naming updated for consistencyThe dependency has been appropriately renamed from
typescriptConfigtotypescriptSetupto match the import change, ensuring code consistency.
21-54: Improved TypeScript configuration APIThe method for setting TypeScript configuration has been updated from method-based calls to a more structured property-based approach:
typescriptSetup.version.set(...)instead oftypescriptConfig.setTypescriptVersion(...)typescriptSetup.compilerOptions.set(...)instead oftypescriptConfig.setTypescriptCompilerOptions(...)This property-based approach is more intuitive and makes the configuration more readable. The second parameter 'react' also helps with traceability by indicating the source of the configuration.
The compiler options themselves are well-structured with clear sections for Compilation, Linting, Resolution, Output, and Paths.
55-58: Array manipulation API improvedThe methods for adding includes and references have been changed from:
typescriptConfig.addInclude(...)totypescriptSetup.include.push(...)typescriptConfig.addReference(...)totypescriptSetup.references.push(...)This is more intuitive as it directly manipulates arrays rather than using custom methods, making the code more aligned with standard JavaScript practices.
packages/fastify-generators/src/generators/core/fastify/setup-fastify-typescript.ts (3)
3-3: Updated import type aligned with output provider conceptThe change from
TypescriptConfigProvidertoTypescriptSetupProvideris aligned with the PR objective of introducing output providers.
10-10: Updated parameter type consistent with import changeThis parameter type update keeps the function signature consistent with the imported type.
12-34: Improved TypeScript configuration with structured approachThe function now uses a more structured approach to TypeScript configuration:
- Uses
version.setinstead ofsetTypescriptVersion- Uses
compilerOptions.setinstead ofsetTypescriptCompilerOptions- Passes a context string 'fastify' to both methods
This implementation successfully adopts the new output provider pattern while maintaining the same functionality.
packages/sync/src/utils/create-setup-task.ts (5)
21-40: Well-documented interface with clear purposeThe
CreateSetupTaskOptionsinterface provides a clear structure for setup task configuration with comprehensive JSDoc comments.
42-49: Type-safe result tuple with clear component rolesThe
SetupTaskResulttype provides a well-structured tuple that preserves type information and clearly identifies the purpose of each component.
58-66: Clean function signature with good parameter handlingThe function signature with a schema builder function and destructured options provides a clean, expressive API. The default taskName parameter is a nice touch for convenience.
67-72: Effective provider type creation with consistent namingThe implementation creates two provider types with consistent naming conventions, clearly distinguishing between configuration and output providers.
74-91: Clean task implementation with field map integrationThe task implementation successfully:
- Creates a task with appropriate exports and outputs
- Uses field maps for configuration
- Provides a build method that extracts values from the field map
This approach creates a clear separation between configuration and output, aligning with the PR objective of introducing output providers.
packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (4)
5-5: Added output provider type importThis import adds support for creating explicit output providers.
30-31: Switched to output provider type for clear intentChanging to
createOutputProviderTypemakes it explicit that this provider is intended for output generation, aligning with the PR objective of introducing output providers.
38-45: Improved task structure with explicit outputsThe task definition now:
- Uses a more descriptive 'main' task name
- Explicitly defines outputs for the
prismaCrudServiceprovider- Exports the provider at both default and project scopes
This change makes the provider's role as an output clearer and aligns with the PR's output provider concept.
65-75: Simplified build method with focused outputThe build method now returns a more concise structure focused solely on the
prismaCrudServiceprovider, which aligns with the output provider pattern.packages/fastify-generators/src/generators/core/root-module/index.ts (9)
14-14: Added createSetupTask importThis import enables the creation of standardized setup tasks using the new utility.
32-42: Used createSetupTask for consistent task creationThe implementation creates a setup task using the new
createSetupTaskutility, which:
- Initializes a map for module fields
- Specifies the appropriate prefix and configScope
- Returns both config and output providers
This change adopts the new standardized approach for creating setup tasks.
43-43: Exported rootModuleConfigProvider for external useExporting the config provider allows other modules to interact with the configuration.
72-72: Added setup task to the task builderThis line adds the newly created setup task to the task builder.
103-106: Updated dependencies to include rootModuleSetupAdding the dependency on
rootModuleSetupensures the setup task runs before the app module task and provides access to the moduleFields map.
108-109: Updated run function to use moduleFields from rootModuleSetupThe run function now:
- Destructures to access moduleFields from rootModuleSetup
- Uses a standard Map instead of a custom non-overwriteable map
This change simplifies the implementation while maintaining the same functionality.
116-116: Updated field validation to reference moduleFieldsMapThis change ensures field validation is performed against the moduleFields map provided by the setup task.
121-126: Simplified entry management logicThe entry management logic now:
- Validates field names against moduleFieldsMap
- Uses a more concise approach for appending entries
This makes the code easier to read and maintain.
152-154: Streamlined module field processingThe module field processing has been simplified to directly map over moduleFieldsMap entries, making the code more concise and readable.
packages/sync/src/runner/dependency-sort.unit.test.ts (6)
3-6: Good addition of the required imports for output provider testing.The updated imports correctly include both
createOutputProviderTypeandcreateProviderType, which are essential for the new tests you've added.
56-63: Well-structured test suite for provider dependencies.This new test suite appropriately defines different provider types (regular, output, and read-only) that will be used throughout the tests. The setup is clean and follows good testing practices.
64-88: Good test for output provider dependency sorting.This test correctly verifies that tasks with output provider dependencies are sorted so that producer tasks complete their build phase before consumer tasks can start. This is a critical behavior for the output provider concept.
90-127: Comprehensive test for mixed provider dependencies.This test effectively validates the sorting behavior when a consumer has dependencies on both output providers and regular providers. The expected steps ensure that output producers complete their build before the consumer is initialized, which is the correct behavior.
129-153: Good coverage of read-only provider dependencies.This test validates that read-only providers are handled correctly in the dependency sorting logic. The comment on line 149 correctly explains that the build order doesn't matter for read-only providers, which is helpful documentation.
155-205: Excellent test for complex dependency chains.This test thoroughly validates how the dependency sorting logic handles complex scenarios with multiple types of providers and dependency relationships. The expected build order correctly respects all types of dependencies.
packages/sync/src/runner/dependency-map.unit.test.ts (6)
20-22: Good addition of outputOnlyProvider for tests.Creating a provider specifically for testing output providers with the
isOutput: trueoption is a good approach. This will help test the unique behavior of output providers.
367-411: Thorough test for recursive dependencies.This test effectively validates that the task dependency resolution works correctly across multiple levels of entries (root, middle, leaf). The use of
parentScopeOnly()tests an important aspect of scope inheritance.
464-500: Good test coverage for output-only providers.This test verifies that output-only providers are correctly handled in the dependency map, ensuring that the
isOutput: trueoption is properly passed through to dependent tasks.
502-531: Important test for intra-generator task dependencies.This test validates an important use case: tasks within the same generator entry can have producer-consumer relationships. This is essential for complex generators that need to sequence their internal operations.
533-552: Good validation of output provider constraint.This test ensures that the system correctly prevents using regular (non-output) providers in task outputs, which is an important validation to maintain the integrity of the output provider concept.
554-572: Good validation of non-output provider constraint in exports.This complementary test ensures that output-only providers cannot be used in regular exports, completing the validation of provider type constraints. This helps prevent misuse of the API.
packages/fastify-generators/src/generators/core/service-file/index.ts (4)
12-13: Good import of the new output provider creator function.Adding the import for
createOutputProviderTypewhile keeping the existingcreateProviderTypeis appropriate for the changes in this file.
50-51: Correctly updated serviceFileOutputProvider to use output provider type.Converting
serviceFileOutputProviderfrom a regular provider to an output provider usingcreateOutputProviderTypealigns with the PR objective of introducing output providers.
58-70: Good implementation of task outputs.The addition of the
outputsproperty to the task definition properly implements the output provider concept. The conditional export based ondescriptor.idis a nice touch that allows for flexible scoping.
120-133: Streamlined return structure from run method.The simplified return structure from the run method removes unnecessary complexity while maintaining the same functionality. This is a good refactoring that makes the code more maintainable.
packages/sync/src/generators/generators.unit.test.ts (5)
1-24: Good helper function for type testing.The
createTaskhelper function is well-designed to allow for proper type inference in the tests. The imports and type definitions are appropriately set up for comprehensive type testing.
25-60: Thorough type inference testing.This test suite effectively validates that the type inference system works correctly with provider export and dependency maps. The use of
expectTypeOfassertions ensures the type system behaves as expected.
62-73: Good coverage of basic task case with no exports.This test verifies the most basic case of a generator task with no exports, ensuring the return type is correctly inferred and the task is properly created.
75-91: Good test for tasks with output providers only.This test validates the case where a task has output providers but no regular exports, which is an important case to test with the new output provider concept.
93-113: Complete test for tasks with both exports and outputs.This test ensures that the most complex case (tasks with both regular exports and output providers) works correctly, which is crucial for fully validating the type system for the new feature.
packages/sync/src/utils/create-generator.ts (4)
12-12: Updated provider imports to support output providersThe addition of
ProviderandProviderExportScopetypes from the providers module enhances type safety and supports the new output provider functionality.
96-96: Simplified type signature for better maintainabilityThe task configuration type has been simplified from a complex generic type to just
SimpleGeneratorTaskConfig[]. This aligns with the PR objective of streamlining the generator framework by eliminating the need for explicit task dependencies.
99-99: Added generatorName to taskBuilderIncluding the generator name in the task builder provides better context awareness for tasks, which is useful for debugging and logging.
118-152: Restructured task implementation to support output providersThe task implementation has been updated to include:
- Support for the new
outputsproperty (line 124)- Improved return handling in the
buildmethod to return an empty object instead of undefined- Simplified taskDependencies extraction
These changes correctly implement the output provider concept mentioned in the PR objectives, allowing tasks to export outputs that will be utilized once they complete building.
packages/fastify-generators/src/generators/core/request-service-context/index.ts (4)
16-17: Added createOutputProviderType to support the output provider conceptAdded import of
createOutputProviderTypewhile maintaining backward compatibility by keeping the existingcreateProviderTypeimport. This supports the implementation of the new output provider concept.
56-59: Changed requestServiceContextProvider to use output provider patternUpdated
requestServiceContextProviderto usecreateOutputProviderTypeinstead ofcreateProviderType. This converts it to follow the new output provider pattern, allowing it to be properly utilized by consumers after the task has completed building.
77-80: Added output configuration to setup taskAdded an
outputsproperty to the task configuration, which exports therequestServiceContextprovider. This enables other tasks to consume this provider as an output rather than through task dependencies.
170-175: Simplified return structure of the build methodThe build method now directly returns the
requestServiceContextobject, which streamlines the code and makes it more clear what output the task is producing. This is in line with the PR objective of eliminating the necessity for task dependencies.packages/fastify-generators/src/generators/pothos/pothos/index.ts (7)
21-22: Added createOutputProviderType and updated importsAdded import for
createOutputProviderTypeand updatedyogaPluginSetupProvidertoyogaPluginConfigProvider. This change supports the new output provider pattern and normalizes the naming convention to use "config" instead of "setup".Also applies to: 31-31
51-55: Created pothosSetupOutputProvider for encapsulating configurationCreated a new output provider type using
createOutputProviderTypethat encapsulates configuration, schema files, and Pothos types. This follows the output provider pattern, making these objects available as outputs to dependent tasks.
65-67: Added pothosSchemaOutputProvider for schema filesCreated a dedicated output provider for schema files, following the same pattern as the setup output provider. This separation of concerns makes it clearer which outputs are available from different tasks.
78-85: Updated setup task to use output providersThe setup task now:
- Uses an inline task definition instead of a separate variable
- Includes outputs property with
pothosSetupOutput- Has a simplified build method that returns the output directly
These changes align with the PR's goal of streamlining task outputs and dependencies.
Also applies to: 114-116
121-151: Refactored schema task to use output providersThe schema task now directly consumes the
pothosSetupOutputand produces apothosSchemaOutput. This demonstrates how the output provider pattern enables cleaner data flow between tasks, as outputs from one task become direct inputs to another.
164-167: Updated main task dependencies to use output providersThe main task now:
- Uses
yogaPluginConfiginstead ofyogaPluginSetup- Depends on
pothosSetupOutputandpothosSchemaOutput- Destructures these outputs directly in the parameters
This simplifies the dependency chain and makes the data flow between tasks more explicit.
Also applies to: 172-182
296-324: Updated yoga configuration handlingThe code now uses
yogaPluginConfigto manage schema settings and post-schema blocks. This is more consistent with the updated pattern of using config providers instead of setup providers throughout the codebase.packages/fastify-generators/src/generators/auth/auth/index.ts (6)
9-9: Added createSetupTask utilityImported
createSetupTask, which provides a more structured way to create setup tasks with configuration schemas.
15-28: Replaced manual provider definitions with createSetupTaskImplemented a cleaner approach using
createSetupTaskto define the configuration schema with properly typed fields. This utility creates both the task and the associated providers in one operation, reducing boilerplate and improving type safety.
29-31: Simplified provider exports and type definitionExported both
authConfigProviderandauthSetupProviderdirectly from thecreateSetupTaskresult and simplified theAuthProviderto just extendImportMapper. This reduces redundancy and improves consistency with the rest of the codebase.
42-43: Simplified task builder by using setupTask directlyInstead of manually implementing the setup task, the code now directly adds the generated setup task to the task builder. This standardizes how setup tasks are created across the codebase.
46-56: Updated main task dependencies and parameter destructuringThe main task now depends on
authSetupand directly destructures the imported configuration properties in the parameters. This makes the code more concise and clearer about which configuration properties are being used.
57-80: Improved error handling and import usageThe error checking now directly validates the destructured imports, and the import map uses these imports directly. This approach is more straightforward and makes the relationship between configuration and usage clearer.
packages/core-generators/src/generators/node/typescript/index.ts (13)
130-143: Evaluate target-library mismatch in compiler settings.The
target: 'es2022'combined withlib: ['es2023']might lead to subtle compatibility issues or transpilation discrepancies for certain newer features.Would you like to check the official TypeScript documentation or run a web search to confirm that this mismatch won’t cause problems in your environment?
146-164: Setup task creation looks sound.Defining both
compilerOptionsand references within a single setup task is a concise approach. Ensuring these options are consistently applied across multiple tasks will streamline TypeScript configuration management.
165-166: Clean export statements.Exporting both
typescriptConfigProviderandtypescriptSetupProvidertogether clarifies their relationship and makes them straightforward to import.
167-169: Type inference strategy is correct.Using
InferProviderTypeto defineTypescriptConfigProviderensures types remain in sync with the underlying provider.
171-173: Seamless inference of setup provider type.Similarly, the
TypescriptSetupProvidertype effectively ties the type information to the provider creation.
180-180: Setup task invocation.Adding
taskBuilder.addTask(setupTask)ensures that compiler configuration is established before other tasks run. No issues spotted.
184-187: New dependency injection.Defining
typescriptConfigas a dependency aligns well with the newly introduced providers, standardizing task usage.
190-190: Destructuring for clarity.Pulling out
compilerOptionsfromtypescriptConfigimproves readability and focuses the subsequent logic on the relevant properties.
193-193: Helper function extraction.Moving path resolution logic into
getPathEntries()is an elegant way to keep the main task function succinct.
195-195: Conditional path logic.Checking for no
pathsand a minimalbaseUrlprovides a good fallback for simpler projects.
224-224: Fallback to 'node' resolution.Defaulting module resolution to
'node'if not explicitly configured is sensible for Node-based projects.
270-271: Destructuring multiple config properties.Extracting additional fields (
include,exclude, etc.) fromtypescriptConfigkeeps build logic modular.
299-302: Default destructuring for missing compiler options.Providing fallback values (
baseUrl = '.',paths = {},moduleResolution = 'node') prevents runtime errors if omitted.packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (4)
11-11: New output provider import.Introducing
createOutputProviderTypesuggests you’re leveraging the new output provider concept to streamline how this generator exports results.
131-134: Clear embedded form setup provider.Defining an output provider for
inputFieldsandtableColumnsis a great approach to separate read/write responsibilities from the rest of the generator.
136-179: Well-structured 'setupForm' task.This task accumulates embedded form inputs and columns, then cleanly exports them via
adminCrudEmbeddedFormSetup. Using separate containers for input and column logic keeps the code decoupled and modular.
180-420: Comprehensive main task logic.
- Dynamic schema generation: Dynamically builds a Zod schema based on
inputFieldsand optionalidField.- Reusable data dependencies: Merging data dependencies for both form inputs and table columns ensures consistent data loading.
- Conditional path: Handling the “list” vs. “object” scenario for embedded forms is neatly implemented, and generating extra props where needed is clean.
- Output file creation: Rendering the final TSX file with time-saving utility methods (like
mergeExpressions) is clear and maintainable.Overall, this main task is robustly structured for an admin CRUD embedded form flow.
packages/fastify-generators/src/generators/core/fastify/index.ts (8)
8-8: Switched to correct TypeScript provider import.Importing
typescriptSetupProviderensures the new setup-based config is accessible.
13-13: Output provider creation import.Bringing in
createOutputProviderTypealigns with the push toward more standardized output-based providers.
60-60: Fastify output provider defined.Creating
fastifyOutputProvideras an output clarifies its usage for exposing final flags and dev output formatting.
73-73: Disabling ESM effectively.Using
nodeSetup.isEsm.set(false, taskBuilder.generatorName);is a clean, centralized toggle for ESM usage, reducing confusion in Node-based workflows.
83-83: Swapping 'typescriptConfig' for 'typescriptSetup'.Renaming to
typescriptSetupkeeps it consistent with the newly introduced setup-based approach across the codebase.
85-85: Applying TypeScript configuration.
setupFastifyTypescript(node, typescriptSetup);is neatly encapsulated, letting you configure TypeScript specifics for Fastify in one place.
100-102: Explicit fastify output export.Adding the
fastifyOutputexport clarifies how other tasks or projects can consume output specifics (e.g., node flags).
152-173: Final output object.Exposing
getNodeFlags(),getNodeFlagsDev(),getNodeFlagsProd(), andgetDevOutputFormatter()in the build step makes runtime configuration easily discoverable. This pattern is a clear demonstration of output providers in practice.packages/sync/src/runner/dependency-map.ts (12)
11-21: Consider validating partial entries at runtime.Marking
GeneratorIdToScopesMapas aPartial<Record<...>>implies that some generator IDs may be missing from the map. Ensure that all consumers handle absent or undefined entries safely to avoid runtime errors or silent failures.Would you like me to generate a quick script to grep for unchecked
generatorIdToScopesMap[...]accesses that might cause undefined errors?
43-63: Robust checks for exports and outputs.These validations properly ensure that exports aren't accidentally marked as output providers, and vice versa. The error messages are clear and will help maintain correct configurations.
71-71: Potential null reference for scope.name.When calling
includes(scope.name), confirmscopeis never null or undefined, or handle it gracefully to avoid runtime errors.
84-84: Destructuring for clarity.Extracting
providersfromgeneratorEntryclarifies usage. Continue verifying thatprovidersis always defined before use.
132-132: Renaming parameter.
parentEntryIdsWithSelfclarifies that the current task’s own ID is included. The naming is a welcome improvement for readability.
142-142: Expanded dependency options.Destructuring
isOutputet al. fromnormalizedDep.optionsis consistent with the new output provider paradigm.
145-145: Provider ID construction.Creating a unique string identifier for each provider/export pair is a solid approach to preventing collisions. No concerns here.
152-155: Use offindLast.
findLastis a modern ECMAScript feature. Verify that the target environment or build chain supports it. Otherwise, a polyfill or alternative approach may be needed.Do you want a script to grep the codebase for other instances of
findLastto verify environment support?
160-160: Optional chain usage.
generatorIdToScopesMap[parentEntryId]?.providersis appropriate for uncertain references. Good defensive coding against undefined lookups.
170-177: Circular dependency detection.This error check prevents infinite loops and subtle runtime confusion. The recommended “.parentScopeOnly()” usage is helpful guidance.
178-178: Return statement clarity.Returning the newly resolved object keeps the function self-contained and clear. No issues noted.
193-195: ExtendedEntryDependencyMaptype.Allowing
optionsto store'isReadOnly' | 'isOutput'helps track dependency metadata. This is well-aligned with the new output provider approach.packages/fastify-generators/src/generators/prisma/prisma/index.ts (6)
16-16: Introducing output provider for Prisma.Replacing
createProviderTypewithcreateOutputProviderTypealigns well with the new output-based usage.
65-65: Defining the Prisma output provider.
createOutputProviderType<PrismaOutputProvider>('prisma-output')is consistent with the pattern of identifying specialized providers. Looks good.
81-81: Refactored task creation.This updated setup for the Prisma generator tasks better reflects the new “outputs” approach in the codebase.
92-92: Adding Prisma outputs.Declaring
{ prismaOutput: prismaOutputProvider.export(projectScope) }cleanly exposes the output provider from this task. Straightforward and in line with the PR objective.
175-178: New signature withaddTaskOutput.Passing
{ schemaFile }back viaaddTaskOutputclarifies how to share build results. This is a positive improvement toward encapsulated build steps.
221-221: CallingaddTaskOutput.Using the newly introduced callback ensures that the
schemaFileis properly exposed to downstream tasks. Good consistency with the API.packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (11)
2-5: Importing field-map utilities.You’re leveraging
FieldMapValuesandInferFieldMapSchemaFromBuilderto define typed schema configurations. This import is consistent with the new approach to typed config.
17-17: Adopting createOutputProviderType.Replacing a standard provider with an output provider clarifies that this plugin setup is intended to produce final outputs rather than internal dependencies.
20-23: Field map creation methods.Importing
createFieldMapandcreateFieldMapSchemaBuilderindicates a move toward applying typed schema definitions for plugin configuration. This is a strong approach for type safety.
46-65: Building schema for plugin configuration.Defining a new field map schema using arrays and scalars fosters clarity. This approach is beneficial for ensuring typed plugin settings.
66-67: Extending configuration interface.
YogaPluginConfigProviderextends the typed schema builder and addsisSubscriptionEnabled(). Clean separation of logic.
71-72: Dedicated config provider.
yogaPluginConfigProviderneatly centralizes this plugin’s config, supporting the new design pattern.
74-77: Setting up a specialized output provider.
yogaPluginSetupProviderusescreateOutputProviderTypefor returning the final field map values. This ensures tasks can register them as outputs.
85-89: Export vs. outputs usage.The
setuptask exportsyogaPluginConfigbut also providesyogaPluginSetupas an output. This aligns perfectly with the new approach of splitting internal vs. final providers.Also applies to: 91-91
94-94: Creating the config field map.
createFieldMap(schemaBuilder)is a succinct approach to building and retrieving typed configuration values. Straightforward and effective.
104-106: ReturninggetValues()as setup output.Exposing
configMap.getValues()ensures the final output remains immutable from outside, aligning with read-only provider principles.
138-138: Referencing yogaPluginSetup in main.The updated dependencies reference
yogaPluginSetupProviderand retrieveconfigfor build. This centralizes the plugin’s final configurations, clarifying the pipeline flow.Also applies to: 140-148
packages/sync/src/providers/providers.ts (11)
8-11: Consider verifying widened Provider type.Changing from a function-based record to a record of unknown values may reduce type safety. If this is deliberate (to store additional non-function data), please confirm no unintended usage conflicts or type mismatches across the codebase.
33-36: Good addition of theisOutputproperty.This clarifies that the provider is used as a read-only output provider, helping readers differentiate output providers from other provider types.
47-47: Inference helper looks good.Using conditional types to infer the provider interface is a clean approach for type safety.
58-65: Check duplication ofisOutputinProviderDependencyOptions.
isOutputis declared both here and inProviderType. If these flags can differ, it may cause confusion. Otherwise, consider consolidating or clarifying their usage.Also applies to: 70-75
118-118: Consistent usage ofisOutput.Enforcing a non-optional boolean here ensures clarity that all exports declare whether they are an output provider or not.
142-146: PropertyisOutputinProviderTypeOptionsis consistent.Defining
isOutputat the options level mirrors other new fields and maintains alignment with the broader provider concept.
182-185: PassingisReadOnlyandisOutputinto dependency options.This maintains consistency across dependencies and the overarching provider metadata.
206-208: Implementation ofparentScopeOnlyaligns well with the new flag.Straightforward usage of
toMergedto setuseParentScopekeeps the dependency logic clean.
215-215: DefaultingisOutputtofalseis a solid fallback.Ensuring a sensible default helps avoid accidental classification as an output provider.
226-226: No meaningful change here.
227-239:createOutputProviderTypeimplementation is straightforward.Neatly wraps
createProviderTypewithisOutput: true, simplifying the creation of output providers.packages/utils/src/field-map/field-map.ts (12)
1-19: BaseFieldContainerdesign looks solid.The approach of storing a private
_value, a default value, and asetValuemethod is clear and encapsulates state well.
21-34:ScalarContainerenforcement of single assignment is well done.Providing a
sourcestring is especially helpful for debugging overwrite attempts.
36-59:ArrayContaineris flexible, with optional de-duplication.Allowing separate toggles for duplicate removal can cover a wide variety of use cases.
61-100:ObjectContainermerges default values with newly set keys effectively.The
merge()method elegantly reusesset(), simplifying the setting logic.
102-147:MapContainernicely extends the container concept to maps.Support of both
merge()andmergeObj()covers typical use cases for map-based data structures.
149-150:InferFieldContainertype is succinct.Extracting the inner value type from any container ensures consistent usage in larger type definitions.
151-158:FieldMapSchemaandFieldMapValuessupport typed retrieval.This design ensures that calling
getValues()returns the correct shape of data.
159-162:FieldMaptype extends the schema with a user-friendly interface.Including
getValues()on the returned map fosters clarity in data handling.
164-212:FieldMapSchemaBuildersystematically provides typed containers.Provisioning methods for scalar, array, object, etc., yields a fluent API for complex field definitions.
214-218:createFieldMapSchemaBuilderis a clean factory approach.Delegating schema construction to a builder function is consistent and portable.
220-223:InferFieldMapSchemaFromBuilderutility type is well-defined.Promotes reusability when we need to infer schema types from custom builders.
227-246:createFieldMapfinal assembly is well-structured.Wrapping the schema with a
getValues()method completes the fluent approach, allowing easy data retrieval.packages/utils/src/field-map/field-map.unit.test.ts (1)
1-175: Comprehensive test suite forFieldMapfunctionality.Tests cover scalar, array, object, and map containers thoroughly, verifying default values, single vs. multiple assignments, and merging behaviors. This ensures robust validation of the new field containers.
packages/sync/src/generators/generators.ts (8)
46-50: Type consistency for handling undefined.This updated conditional type properly returns
undefinedifTisundefined, enhancing clarity and correctness in usage.
55-59: Aligns with InferExportProviderMap.Similarly, this definition cleanly mirrors the logic above, ensuring undefined is returned when the type parameter is undefined.
85-85: Interface naming is consistent.
GeneratorTaskResultBuildersWithNoOutputscomplements the “with outputs” interface. No issues found.
92-97: Neat utility type.
IsEmptyis helpful for building conditional types. This looks fine, but keep in mind how optional or index-signature properties might affect the detection of an “empty” object.
122-128: Optional output bridging.Adding
OutputMapto the type parameters onGeneratorTaskallows more flexible usage without forcing outputs on every task.
138-141: Introducing outputs property.Exposing
outputs?: OutputMapclarifies that a generator task may produce providers beyond its exports, aligning with the new output provider concept.
157-160: Return type updated for new structure.Tying
runintoGeneratorTaskResultrespects both exports and outputs. The changes appear consistent with the rest of the file.
98-116:Details
❓ Verification inconclusive
Verify “OutputMap extends true” usage.
This intersection type logic is well-structured overall. However, the condition
OutputMap extends truein line 111 is unusual—please confirm if this is intended, or if you meant to checkOutputMapdifferently.Please run the following command to locate references and confirm usage:
🏁 Script executed:
#!/bin/bash rg "OutputMap extends true"Length of output: 98
Clarify the Intent of the
OutputMap extends trueCheck
- The intersection type logic is well-organized, but the condition
OutputMap extends truein line 111 appears unusual.- The grep search confirms this is the only instance of this pattern in the repository.
- Please confirm whether this usage is intentional—for example, to signal that no output builders should be generated—or if it should be replaced by a check (such as using
IsEmpty<OutputMap>) similar to howExportMapis handled.- If the current logic is correct, consider adding an inline comment to clarify its purpose for future maintainers.
packages/sync/src/utils/create-generator-types.ts (8)
48-64: Flexible type parameters for optional outputs.Enabling
ExportMapandOutputMapto beundefinedhelps in tasks that may not export or produce any providers. Thebuildfunction signature is now more expressive, accommodating additional task outputs.
74-107: Extended configuration for outputs.
SimpleGeneratorTaskConfignow supports anOutputMap, providing stronger typing for generator outputs. This design should streamline tasks that only sometimes produce outputs.
109-112: Refined TaskConfigBuilder type.Allowing
OutputMapto be optional here is consistent with the rest of the changes, permitting tasks to declare outputs only if needed.
131-131: Extracting task output.The reference to
ProviderExportMapinExtractTaskOutputFromBuildercleanly extends the existing pattern for extracting typed outputs.
138-142: Task builder map flexible outputs.This extension ensures each builder can declare its own exports and outputs. No immediate issues identified.
153-157: createTaskConfigBuilder with optional outputs.Providing defaults for
ExportMapandOutputMapfurther refines tasks that might only produce side effects. The approach seems well-integrated.
183-184: Explicit generatorName usage.Introducing a
generatorNameproperty into the builder interface clarifies the source or identity of the tasks being built. Looks good.
185-209: Extended addTask signature.Allowing each task to independently specify whether it uses an
OutputMapfosters modular, reusable creations without imposing outputs on every task configuration.
| id: 'simple:output', | ||
| contents: 'output', |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Check ID consistency in test expectations
There appears to be a mismatch between the IDs used in builder.writeFile() calls ('output', 'consumer') and the expected IDs in the test assertions ('simple:output', 'simple:consumer').
Verify that this is intentional behavior or if there might be a mistake in the test expectations:
Also applies to: 247-248
🏁 Script executed:
#!/bin/bash
# Search for any code that might explain ID transformation logic
rg -A 2 "id: '.*?'" --glob "*.ts" | grep -v "file_id" | head -n 20Length of output: 1703
Action Required: Confirm and Fix ID Prefix Mismatch
Our search did not reveal any transformation logic that would add a "simple:" prefix to file IDs. In other parts of the codebase (e.g., in the generators for eslint, prettier, etc.), IDs are defined without any such prefix. Meanwhile, the test in packages/sync/src/runner/generator-runner.unit.test.ts (lines 242‑243 and 247‑248) expects IDs like "simple:output" and "simple:consumer", suggesting an inconsistency between the generated file IDs (e.g., "output" and "consumer") and what the tests assert.
Please verify if the test expectations should be updated to match the actual IDs from builder.writeFile() or if the generator should apply the "simple:" prefix as intended. Reviewing and resolving this inconsistency will prevent potential assertion failures in future test runs.
| prismaOutput: { | ||
| getImportMap: () => ({ | ||
| '%prisma-service': { | ||
| path: '@/src/services/prisma.js', | ||
| allowedImports: ['prisma'], | ||
| }, | ||
| }), | ||
| getPrismaServicePath: () => '@/src/services/prisma.js', | ||
| getPrismaClient: () => | ||
| TypescriptCodeUtils.createExpression( | ||
| 'prisma', | ||
| "import { prisma } from '@/src/services/prisma.js'", | ||
| ), | ||
| getPrismaModel: (modelName) => { | ||
| const modelBlock = schemaFile.getModelBlock(modelName); | ||
| if (!modelBlock) { | ||
| throw new Error(`Model ${modelName} not found`); | ||
| } | ||
| return modelBlock; | ||
| }, | ||
| }), | ||
| getPrismaServicePath: () => '@/src/services/prisma.js', | ||
| getPrismaClient: () => | ||
| TypescriptCodeUtils.createExpression( | ||
| 'prisma', | ||
| "import { prisma } from '@/src/services/prisma.js'", | ||
| ), | ||
| getPrismaModel: (modelName) => { | ||
| const modelBlock = schemaFile.getModelBlock(modelName); | ||
| if (!modelBlock) { | ||
| throw new Error(`Model ${modelName} not found`); | ||
| } | ||
| return modelBlock; | ||
| }, | ||
| getServiceEnum: (name) => { | ||
| const block = schemaFile.getEnum(name); | ||
| if (!block) { | ||
| throw new Error(`Enum ${name} not found`); | ||
| } | ||
| return { | ||
| name: block.name, | ||
| values: block.values, | ||
| expression: TypescriptCodeUtils.createExpression( | ||
| block.name, | ||
| `import { ${block.name} } from '@prisma/client'`, | ||
| getServiceEnum: (name) => { | ||
| const block = schemaFile.getEnum(name); | ||
| if (!block) { | ||
| throw new Error(`Enum ${name} not found`); | ||
| } | ||
| return { | ||
| name: block.name, | ||
| values: block.values, | ||
| expression: TypescriptCodeUtils.createExpression( | ||
| block.name, | ||
| `import { ${block.name} } from '@prisma/client'`, | ||
| ), | ||
| }; | ||
| }, | ||
| getPrismaModelExpression: (modelName) => { | ||
| const modelExport = | ||
| modelName.charAt(0).toLocaleLowerCase() + | ||
| modelName.slice(1); | ||
| return TypescriptCodeUtils.createExpression( | ||
| `prisma.${modelExport}`, | ||
| "import { prisma } from '@/src/services/prisma.js'", | ||
| ); | ||
| }, | ||
| getModelTypeExpression: (modelName) => | ||
| TypescriptCodeUtils.createExpression( | ||
| modelName, | ||
| `import { ${modelName} } from '@prisma/client'`, | ||
| ), | ||
| }; | ||
| }, | ||
| getPrismaModelExpression: (modelName) => { | ||
| const modelExport = | ||
| modelName.charAt(0).toLocaleLowerCase() + modelName.slice(1); | ||
| return TypescriptCodeUtils.createExpression( | ||
| `prisma.${modelExport}`, | ||
| "import { prisma } from '@/src/services/prisma.js'", | ||
| ); | ||
| }, | ||
| getModelTypeExpression: (modelName) => | ||
| TypescriptCodeUtils.createExpression( | ||
| modelName, | ||
| `import { ${modelName} } from '@prisma/client'`, | ||
| ), | ||
| }, | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Comprehensive Prisma output methods.
This block provides complete model, enum, and client references. The additional error handling for missing models/enums is good. Consider unit tests to ensure coverage of all these getters.
Would you like me to propose a small test suite demonstrating usage and error conditions for these methods?
kingston
deleted the
kingston/eng-590-introduce-output-provider-system-to-replace-task
branch
Allow tasks to export output providers that will be used consumed when the task has finished building. This replaces the need for task dependencies.
Summary by CodeRabbit
New Features
Refactor / Improvements
Documentation