Skip to content

Conversation

@kingston
Copy link
Collaborator

@kingston kingston commented Apr 7, 2025

  • also refactor output providers to use readOnly providers only instead of output providers

Summary by CodeRabbit

  • New Features

    • Enhanced import map functionality for improved dependency resolution.
    • Asynchronous file generation accelerates code output.
  • Refactor

    • Provider interactions are now streamlined with a read-only approach.
    • Logging and error handling integrations have been reorganized for greater consistency.
    • Updated task handling for TypeScript file generation enhances modularity.
  • Chores & Tests

    • Configuration improvements include new file-watch options.
    • Expanded unit tests bolster stability and ensure robust dependency management.

@linear
Copy link

linear bot commented Apr 7, 2025

ENG-603 Introduce new system for passing around imports between providers

Currently we use importMaps but they are fragile and not typed so we should switch to a new system where we can pass in the

@changeset-bot
Copy link

changeset-bot bot commented Apr 7, 2025

⚠️ No Changeset found

Latest commit: aa9b92d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link

coderabbitai bot commented Apr 7, 2025

Walkthrough

This pull request introduces extensive changes across multiple packages. Core modifications include replacing output provider types with read-only variants, updating asynchronous file generation tasks, and restructuring TypeScript generators. New files and functions related to import map transformations and topological sorting have been added, alongside comprehensive unit tests. Additionally, many import paths and exports have been updated to reflect the new module organization.

Changes

File(s) Change Summary
packages/core-generators/src/generators/node/typescript/index.ts Updated TS generator: replaced GeneratorTask with GeneratorTaskOutputBuilder, updated WriteTemplatedFilePayload and TypescriptFileProvider signatures, and removed createTypescriptFileTask in favor of an inline task in buildTasks.
packages/core-generators/src/providers/project.ts Changed project provider instantiation from output to read-only using createReadOnlyProviderType.
packages/core-generators/src/renderers/typescript/import-maps/{index.ts, transform-ts-imports-with-map.ts, transform-ts-imports-with-map.unit.test.ts, ts-import-map.ts, types.ts} Added new import map files and exports to facilitate TS import declaration transformation, schema creation, and type definitions.
packages/core-generators/src/renderers/typescript/{index.ts, renderers/file.ts, renderers/file.unit.test.ts, templates/creators.ts, templates/types.ts} Updated TS renderers/templates: introduced generic importMapProviders, modified import merging logic, and adjusted export statements.
packages/fastify-generators/src/generators/** Modified multiple Fastify generators: updated import paths, switched providers from output to read-only variants, restructured task dependencies, integrated async file writing, and introduced new config-service import mappings.
packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts Revised provider instantiation for the admin CRUD form by replacing createOutputProviderType with createReadOnlyProviderType.
packages/sync/src/{providers/providers.ts, runner/**, utils/create-config-provider-task*.ts} Replaced createOutputProviderType with createReadOnlyProviderType, removed isOutput in favor of isReadOnly, and updated dependency mapping, sorting, and test helper functions.
packages/tools/tsconfig.node.base.json, packages/utils/src/{index.ts, toposort/**} Added watchOptions to tsconfig; introduced a new topological sort implementation with custom error handling and corresponding unit tests.

Sequence Diagram(s)

sequenceDiagram
    participant Task as Generator Task
    participant TS as TypescriptFile Provider
    participant Builder as Task Builder
    Task->>TS: writeTemplatedFile(builder, payload)
    TS-->>Task: Promise resolves { destination }
Loading
sequenceDiagram
    participant Caller as Caller
    participant Transformer as transformTsImportsWithMap
    participant Map as ImportMap
    Caller->>Transformer: Provide import declarations & import map
    alt Declaration without "%"
        Transformer-->>Caller: Return unchanged declaration
    else Declaration with "%"
        Transformer->>Map: Lookup import key
        alt Key not found or invalid import
            Transformer-->>Caller: Throw error
        else
            Transformer-->>Caller: Return transformed declaration
        end
    end
Loading

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite

📥 Commits

Reviewing files that changed from the base of the PR and between 6c168f9 and aa9b92d.

📒 Files selected for processing (3)
  • packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.unit.test.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/ts-import-map.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/config-service/index.ts (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.unit.test.ts
  • packages/core-generators/src/renderers/typescript/import-maps/ts-import-map.ts
🧰 Additional context used
🧬 Code Definitions (1)
packages/fastify-generators/src/generators/core/config-service/index.ts (1)
packages/fastify-generators/src/generators/core/config-service/generated/import-maps.ts (2)
  • configServiceImportsProvider (17-20)
  • createConfigServiceImportMap (26-32)
🔇 Additional comments (4)
packages/fastify-generators/src/generators/core/config-service/index.ts (4)

29-32: New imports added for TsImportMap system

These new imports bring in the required components for the TsImportMap system, which aligns with the PR objective of refactoring import handling.


84-87: Added configServiceImports to exports object

The addition of configServiceImports to the exports object is consistent with the existing pattern used for configService. This change exposes the import mapping functionality to consumers of this generator task.


124-126: Added new configServiceImports provider

This section creates a new import map provider using the createConfigServiceImportMap function, which is part of the new TsImportMap system. The provider is correctly configured with the service path.


210-210: Re-exporting configServiceImportsProvider

Re-exporting the provider makes it available to other modules that import from this file, which follows good module design practices by providing a clear public API.


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (13)
packages/core-generators/src/renderers/typescript/import-maps/ts-import-map.ts (2)

55-61: Clarify error message about type-only imports.

The error message when attempting to use a type-only import as a regular import could be more descriptive.

-              throw new Error(
-                'Type only imports cannot be marked as named imports',
-              );
+              throw new Error(
+                `Cannot use type-only import '${name}' as a regular import. Use typeDeclaration() instead.`,
+              );

23-67:

Details

❓ Verification inconclusive

Consider clarifying the source prefix convention.

The implementation looks solid, but I noticed that all import sources automatically get prefixed with @/ on line 39. This assumes a specific path alias configuration in the project.


🏁 Script executed:

#!/bin/bash
# Check if the path alias is configured in the tsconfig
grep -r "@/" --include="tsconfig*.json" .

Length of output: 41


Clarify the use of the @/ source prefix

The implementation appears correct, but the code assumes that the @/ prefix is supported by a corresponding alias configuration—typically set up in a TypeScript configuration file (like tsconfig.json). However, our initial search did not reveal any such alias setting. Please verify that this alias is indeed configured in your project (or intended to be backed by another mechanism) and update the documentation or configuration as needed.

packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.ts (1)

19-56: Solid implementation of import transformation with good error handling.

The function correctly handles various cases:

  1. Skips imports not starting with '%'
  2. Extracts import map keys
  3. Validates import map existence
  4. Checks for unsupported import types
  5. Properly transforms named imports based on whether they are type-only

Consider adding a comment explaining the behavior when namedImports is undefined - returning an empty array is correct but might not be immediately obvious to readers:

    return (
      importDeclaration.namedImports?.map((namedImport) => {
        if (!(namedImport.name in importMap)) {
          throw new Error(`Import map entry not found for ${namedImport.name}`);
        }

        const entry = importMap[namedImport.name];

        return importDeclaration.isTypeOnly
          ? entry.typeDeclaration()
          : entry.declaration();
-      }) ?? []
+      }) ?? [] // Return empty array if namedImports is undefined
    );
packages/sync/src/runner/dependency-sort.unit.test.ts (1)

71-71: Revisiting provider naming.

createReadOnlyProviderType('output-provider') might be confusing. If genuinely read-only, consider revisiting the term “output” in the name for clarity.

packages/utils/src/toposort/toposort.ts (1)

44-105: Depth-first search for topological sort.

The DFS-based approach is solid. Consider documenting potential stack depth limits for extremely large graphs. Otherwise, the cycle detection and final ordering logic appear correct.

packages/fastify-generators/src/generators/core/logger-service/logger-service.generator.ts (1)

109-149: Asynchronous file templating logic.

Switching to an async build step to leverage typescriptFile.writeTemplatedFile is an improvement. Consider error handling (try/catch) if file writes fail, possibly returning an informative log or fallback behavior.

packages/sync/src/runner/dependency-map.ts (2)

29-34: New EntryDependencyRecord interface
The addition of isReadOnly and isOutput neatly distinguishes between read-only providers and output providers. Consider adding brief JSDoc comments explaining each field’s role (e.g., “isReadOnly indicates …,” “isOutput indicates …”) for maintainability.


94-98: Duplicate provider detection
The logic to detect existing providers with the same providerId and throw an error if found is crucial to avoid conflicting exports. The error message is very descriptive, though it might be beneficial to mention the exact export name in the error text for clarity.

packages/core-generators/src/renderers/typescript/import-maps/types.ts (1)

3-14: Introducing TsImportMapSchemaEntry
This interface effectively captures optional naming and a boolean flag isTypeOnly. The generic constraint IsTypeOnly allows flexible usage. Consider adding doc comments to clarify how isTypeOnly is employed in the broader system.

packages/sync/src/providers/providers.ts (2)

27-29: Clarify documentation around read-only providers.

These doc lines now correctly emphasize that only read-only providers can serve as outputs. However, consider explicitly linking the concept of “cannot modify state” with the requirement for outputs, so that future readers more readily understand the rationale.


133-133: Existing doc comment appears duplicated.

Lines 27-29 have nearly identical statements regarding read-only providers being used as build outputs. Consider whether the duplication is necessary or if a single, centralized comment would be clearer.

packages/core-generators/src/renderers/typescript/renderers/file.ts (1)

28-31: Solid addition of RenderTsCodeFileTemplateOptionsBase and InferImportMapProvidersFromProviderTypeMap.

The introduction of a base interface and a helper type for inferring provider types makes the code more modular and type-safe. Consider whether any of these fields should be mandatory in the base interface or remain optional, depending on usage patterns across the codebase.

Also applies to: 33-43

packages/core-generators/src/generators/node/typescript/index.ts (1)

286-345: New file generator task consolidates TypeScript file writing logic.

  1. Retrieving compiler options with defaults, generating path mappings, and constructing internal patterns ensures the environment is well prepared.
  2. The typescriptFile provider yields a clean async flow, calling renderTsCodeFileTemplate with the new importMapProviders.
  3. The code then writes to the builder and returns the destination.

Overall, this approach is easy to follow and maintain.

Consider documenting more detailed error handling for any I/O failures in the writeTemplatedFile method if needed.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite

📥 Commits

Reviewing files that changed from the base of the PR and between 2f67423 and 6c168f9.

⛔ Files ignored due to path filters (3)
  • packages/fastify-generators/src/generators/core/config-service/generated/import-maps.ts is excluded by !**/generated/**
  • packages/fastify-generators/src/generators/core/error-handler-service/generated/templates.ts is excluded by !**/generated/**
  • packages/fastify-generators/src/generators/core/logger-service/generated/import-maps.ts is excluded by !**/generated/**
📒 Files selected for processing (49)
  • packages/core-generators/src/generators/node/typescript/index.ts (4 hunks)
  • packages/core-generators/src/providers/project.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/index.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.unit.test.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/ts-import-map.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/import-maps/types.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/index.ts (1 hunks)
  • packages/core-generators/src/renderers/typescript/renderers/file.ts (6 hunks)
  • packages/core-generators/src/renderers/typescript/renderers/file.unit.test.ts (4 hunks)
  • packages/core-generators/src/renderers/typescript/templates/creators.ts (2 hunks)
  • packages/core-generators/src/renderers/typescript/templates/types.ts (3 hunks)
  • packages/fastify-generators/src/generators/auth0/auth0-module/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/bull/bull-mq/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/_composers/fastify-composer.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/config-service/index.ts (4 hunks)
  • packages/fastify-generators/src/generators/core/error-handler-service/index.ts (4 hunks)
  • packages/fastify-generators/src/generators/core/error-handler-service/templates/plugins/error-handler.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/fastify-graceful-shutdown/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/fastify-server/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/fastify/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/core/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/logger-service/logger-service.generator.ts (4 hunks)
  • packages/fastify-generators/src/generators/core/request-context/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/core/request-service-context/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/core/service-context/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/core/service-file/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/email/fastify-sendgrid/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/pothos/pothos/index.ts (3 hunks)
  • packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/prisma/prisma/index.ts (2 hunks)
  • packages/fastify-generators/src/generators/stripe/fastify-stripe/index.ts (1 hunks)
  • packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (3 hunks)
  • packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (2 hunks)
  • packages/sync/src/providers/providers.ts (7 hunks)
  • packages/sync/src/runner/dependency-map.ts (9 hunks)
  • packages/sync/src/runner/dependency-map.unit.test.ts (30 hunks)
  • packages/sync/src/runner/dependency-sort.ts (4 hunks)
  • packages/sync/src/runner/dependency-sort.unit.test.ts (7 hunks)
  • packages/sync/src/runner/generator-runner.ts (1 hunks)
  • packages/sync/src/runner/generator-runner.unit.test.ts (5 hunks)
  • packages/sync/src/runner/tests/dependency-entry.test-helper.ts (1 hunks)
  • packages/sync/src/utils/create-config-provider-task-with-info.ts (2 hunks)
  • packages/sync/src/utils/create-config-provider-task.ts (2 hunks)
  • packages/tools/tsconfig.node.base.json (1 hunks)
  • packages/utils/src/index.ts (1 hunks)
  • packages/utils/src/toposort/index.ts (1 hunks)
  • packages/utils/src/toposort/toposort.ts (1 hunks)
  • packages/utils/src/toposort/toposort.unit.test.ts (1 hunks)
🧰 Additional context used
🧬 Code Definitions (26)
packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.unit.test.ts (3)
packages/core-generators/src/renderers/typescript/imports/types.ts (1)
  • TsImportDeclaration (22-43)
packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.ts (1)
  • transformTsImportsWithMap (19-56)
packages/core-generators/src/renderers/typescript/import-maps/types.ts (1)
  • TsImportMap (30-30)
packages/core-generators/src/providers/project.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/core/request-service-context/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/core/service-context/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/core/service-file/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/core/fastify/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/sync/src/utils/create-config-provider-task.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/prisma/prisma/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/core-generators/src/renderers/typescript/renderers/file.unit.test.ts (2)
packages/core-generators/src/renderers/typescript/renderers/file.ts (1)
  • renderTsCodeFileTemplate (117-177)
packages/core-generators/src/renderers/typescript/ts-code-utils.ts (1)
  • template (161-182)
packages/sync/src/runner/tests/dependency-entry.test-helper.ts (1)
packages/sync/src/runner/dependency-map.ts (1)
  • EntryDependencyRecord (29-34)
packages/sync/src/runner/generator-runner.unit.test.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/sync/src/runner/dependency-sort.ts (1)
packages/utils/src/toposort/toposort.ts (1)
  • toposort (51-104)
packages/sync/src/runner/dependency-map.unit.test.ts (2)
packages/sync/src/providers/providers.ts (2)
  • createProviderType (144-203)
  • createReadOnlyProviderType (212-217)
packages/sync/src/runner/tests/dependency-entry.test-helper.ts (3)
  • createReadOnlyDependencyEntry (22-30)
  • createDependencyEntry (3-20)
  • createOutputDependencyEntry (32-45)
packages/sync/src/runner/dependency-map.ts (1)
packages/sync/src/providers/providers.ts (1)
  • ProviderExport (101-122)
packages/fastify-generators/src/generators/core/logger-service/logger-service.generator.ts (4)
packages/core-generators/src/generators/node/typescript/index.ts (1)
  • typescriptFileProvider (121-122)
packages/fastify-generators/src/generators/core/logger-service/generated/import-maps.ts (2)
  • loggerServiceImportsProvider (17-20)
  • createLoggerServiceImportMap (26-32)
packages/fastify-generators/src/generators/core/logger-service/generated/templates.ts (1)
  • loggerFileTemplate (4-12)
packages/core-generators/src/renderers/typescript/ts-code-utils.ts (1)
  • TsCodeUtils (38-183)
packages/fastify-generators/src/generators/pothos/pothos/index.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/core-generators/src/renderers/typescript/templates/types.ts (1)
packages/sync/src/providers/providers.ts (1)
  • ProviderType (17-40)
packages/fastify-generators/src/generators/core/error-handler-service/index.ts (4)
packages/fastify-generators/src/generators/core/config-service/generated/import-maps.ts (1)
  • configServiceImportsProvider (17-20)
packages/fastify-generators/src/generators/core/logger-service/logger-service.generator.ts (1)
  • loggerServiceProvider (50-53)
packages/core-generators/src/generators/node/typescript/index.ts (1)
  • typescriptFileProvider (121-122)
packages/fastify-generators/src/generators/core/error-handler-service/generated/templates.ts (1)
  • errorHandlerPluginFileTemplate (6-18)
packages/sync/src/utils/create-config-provider-task-with-info.ts (1)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/sync/src/runner/dependency-sort.unit.test.ts (2)
packages/sync/src/runner/tests/dependency-entry.test-helper.ts (3)
  • createDependencyEntry (3-20)
  • createOutputDependencyEntry (32-45)
  • createReadOnlyDependencyEntry (22-30)
packages/sync/src/providers/providers.ts (1)
  • createReadOnlyProviderType (212-217)
packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.ts (2)
packages/core-generators/src/renderers/typescript/imports/types.ts (1)
  • TsImportDeclaration (22-43)
packages/core-generators/src/renderers/typescript/import-maps/types.ts (1)
  • TsImportMap (30-30)
packages/core-generators/src/renderers/typescript/import-maps/types.ts (1)
packages/core-generators/src/renderers/typescript/imports/types.ts (1)
  • TsImportDeclaration (22-43)
packages/core-generators/src/renderers/typescript/renderers/file.ts (4)
packages/core-generators/src/renderers/typescript/imports/types.ts (1)
  • TsImportDeclaration (22-43)
packages/core-generators/src/renderers/typescript/import-maps/types.ts (2)
  • TsImportMap (30-30)
  • TsImportMapProvider (36-38)
packages/core-generators/src/renderers/typescript/imports/ts-morph-operations.ts (1)
  • getTsMorphImportDeclarationsFromSourceFile (19-25)
packages/core-generators/src/renderers/typescript/templates/types.ts (1)
  • TsCodeFileTemplate (19-38)
🔇 Additional comments (126)
packages/react-generators/src/generators/admin/admin-crud-embedded-form/index.ts (2)

12-14: Provider type import change aligns with output provider refactoring.

The import of createReadOnlyProviderType from @halfdomelabs/sync aligns with the PR objective to refactor output providers to read-only providers.


132-135: Changed output provider to read-only provider.

This change from createOutputProviderType to createReadOnlyProviderType is consistent with the PR objective of switching to read-only providers exclusively instead of output providers.

The provider's type signature remains unchanged, preserving its functionality while making it immutable, which is good for preventing unexpected modifications during the generation process.

packages/utils/src/toposort/index.ts (1)

1-2: Clean barrel file for toposort module.

This is a simple and effective re-export pattern (barrel file) for the toposort module, making it easier to import from other parts of the codebase.

packages/utils/src/index.ts (1)

6-7: Correctly exports the toposort module.

This export makes the toposort functionality available to consumers of the utils package, following the same pattern used for other modules in this file.

packages/tools/tsconfig.node.base.json (1)

5-7: Improved file watching configuration for TypeScript.

The addition of the watchOptions configuration with "watchFile": "usefseventsonparentdirectory" can improve TypeScript's file watching performance by using file system events on parent directories rather than polling individual files.

This is particularly useful in large projects where many files need to be watched during development, as it can reduce CPU usage and be more responsive to changes.

packages/fastify-generators/src/generators/core/fastify-graceful-shutdown/index.ts (1)

11-11: Import path refactored to be more specific.

The import path for loggerServiceProvider has been updated to point directly to the generator file instead of the index file. This change is part of the new TsImportMap system being introduced, making import paths more explicit and maintainable.

packages/core-generators/src/renderers/typescript/index.ts (1)

2-2: New export added for import maps system.

This addition exports all the definitions from the import-maps module, which is a key component of the new TsImportMap system mentioned in the PR objectives. This change enables the use of import maps throughout the codebase.

packages/fastify-generators/src/generators/core/request-context/index.ts (1)

24-24: Import path refactored to be more specific.

The import path for loggerServiceSetupProvider has been updated to point directly to the generator file instead of the index file. This change is consistent with the new TsImportMap system being introduced in this PR.

packages/fastify-generators/src/generators/core/index.ts (1)

14-14: Export path refactored to be more specific.

The export path for the logger service has been updated to point directly to the generator file instead of the index file. This change is consistent with the pattern of making import/export paths more explicit throughout the codebase as part of the new TsImportMap system.

packages/fastify-generators/src/generators/auth0/auth0-module/index.ts (1)

26-26: Import path update looks good!

This change from importing from index.js to the more specific logger-service.generator.js aligns with the broader restructuring of logger service imports across the codebase. This approach improves code organization by making import paths more explicit and consistent.

packages/core-generators/src/renderers/typescript/import-maps/index.ts (1)

1-3: Well-structured barrel file for the new import map system!

This clean organization exports functionality from three distinct modules, separating concerns between transformation logic, import map functionality, and type definitions. The use of export type * for types is particularly good practice.

packages/core-generators/src/providers/project.ts (1)

1-1: Good transition to readOnly provider type!

Changing from createOutputProviderType to createReadOnlyProviderType aligns with the PR objective of refactoring output providers to use readOnly providers exclusively. This is a good design decision for the project provider, as it prevents unintended modifications and enforces a clearer consumption pattern.

Also applies to: 8-8

packages/fastify-generators/src/generators/core/_composers/fastify-composer.ts (1)

16-16: Consistent import path update!

This change from ../logger-service/index.js to the more specific ../logger-service/logger-service.generator.js matches the pattern seen across the codebase. It's part of a consistent effort to make import paths more explicit and better organized.

packages/fastify-generators/src/generators/bull/bull-mq/index.ts (1)

20-20: Import path update looks good.

The import path for loggerServiceProvider has been updated to use a more specific path, pointing directly to the generator file. This change is consistent with the refactoring approach described in the PR objectives to introduce the new TsImportMap system.

packages/fastify-generators/src/generators/email/fastify-sendgrid/index.ts (1)

16-16: Import path update looks good.

The import path for loggerServiceProvider has been updated to use a more specific module path, pointing directly to the generator file. This change is consistent with the pattern seen across other files and aligns with the TsImportMap system introduction mentioned in the PR objectives.

packages/fastify-generators/src/generators/stripe/fastify-stripe/index.ts (1)

19-19: Import path update looks good.

The import path for loggerServiceProvider has been updated to use a more specific path, pointing directly to the generator file. This change follows the same pattern as in other files and supports the new TsImportMap system implementation.

packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.unit.test.ts (1)

1-158: Comprehensive unit tests for the new import transformation system.

This test file thoroughly covers the functionality of the transformTsImportsWithMap function, which is a key component of the new TsImportMap system. The tests handle various cases including regular imports, error conditions, and different import types.

The tests are well-structured and cover:

  • Standard imports without transformation
  • Error handling for missing import maps and unsupported import types
  • Proper transformation of named and type-only imports
  • Handling of multiple imports with different target modules

This implementation will help ensure the robustness of the new import handling system.

packages/fastify-generators/src/generators/core/error-handler-service/templates/plugins/error-handler.ts (1)

6-6: Import path updated to use configService

The import path has been updated from %config to %configService, which aligns with the PR objective of introducing a new TsImportMap system for import handling. This change maintains backward compatibility since the code still references the config variable in the same way.

packages/fastify-generators/src/generators/core/service-file/index.ts (2)

14-14: Added import for createReadOnlyProviderType

This import is necessary for the change from output providers to read-only providers as mentioned in the PR objectives.


52-52: Switched to read-only provider type

The provider type has been changed from output to read-only, which improves type safety by preventing modification of the provider's state after initialization. This change aligns with the PR objective of utilizing readOnly providers exclusively instead of output providers.

packages/fastify-generators/src/generators/core/request-service-context/index.ts (2)

18-18: Added import for createReadOnlyProviderType

This import is necessary for the change from output providers to read-only providers as mentioned in the PR objectives.


58-58: Switched to read-only provider type

The provider type has been changed from output to read-only, which improves type safety by preventing modification of the provider's state after initialization. This change aligns with the PR objective of utilizing readOnly providers exclusively instead of output providers.

packages/fastify-generators/src/generators/core/fastify-server/index.ts (1)

25-25: Updated import path for loggerServiceProvider

The import path has been changed from ../logger-service/index.js to ../logger-service/logger-service.generator.js, which is more specific and better reflects the purpose of the imported module. This is consistent with the PR objective of refactoring import handling.

packages/sync/src/runner/generator-runner.ts (2)

95-100: Migration from isOutput to isReadOnly

This code correctly updates the dependency property destructuring to use isReadOnly instead of the previous isOutput. This is part of the new TsImportMap system being introduced in this PR.


105-108: Updated dependency validation for read-only providers

The condition has been updated to check isReadOnly instead of the previous isOutput flag, with a corresponding error message update. This correctly aligns with the architectural shift from output providers to read-only providers.

packages/fastify-generators/src/generators/core/fastify/index.ts (2)

16-16: Added import for createReadOnlyProviderType

The import statement has been updated to include createReadOnlyProviderType for the new provider implementation.


63-64: Updated fastifyOutputProvider to use read-only type

The provider type has been changed from createOutputProviderType to createReadOnlyProviderType, which aligns with the architecture change from output providers to read-only providers.

This change maintains the same interface while changing the provider characteristics to be read-only, ensuring compatibility with the new system.

packages/fastify-generators/src/generators/core/service-context/index.ts (2)

17-17: Added import for createReadOnlyProviderType

The import statement has been updated to include createReadOnlyProviderType for the new provider implementation.


49-50: Updated serviceContextProvider to use read-only type

The provider type has been changed from createOutputProviderType to createReadOnlyProviderType, aligning with the architecture changes in this PR. The interface remains unchanged, ensuring backward compatibility while implementing the new provider type system.

packages/core-generators/src/renderers/typescript/renderers/file.unit.test.ts (4)

21-23: Updated test function call with importMapProviders parameter

This test case has been updated to include the new importMapProviders parameter required by the modified renderTsCodeFileTemplate function. The empty object initialization ensures backward compatibility with existing tests.


47-49: Added importMapProviders parameter to test call

The test case for merging and sorting imports has been properly updated to include the importMapProviders parameter, ensuring compatibility with the updated function signature.


78-81: Added importMapProviders parameter to module resolution test

The test for module resolution has been properly updated to include the importMapProviders parameter, maintaining consistency across all test cases.


120-122: Added importMapProviders parameter to hoisted fragments test

The test for hoisted fragments has been properly updated to include the importMapProviders parameter, ensuring all test cases consistently use the new function signature.

packages/sync/src/utils/create-config-provider-task-with-info.ts (2)

13-14: Import replacement aligns with provider refactoring.

Adding createReadOnlyProviderType to replace the removed createOutputProviderType is consistent with the PR objective of refactoring output providers to read-only providers.


111-113: Provider type change correctly implements read-only behavior.

Changing from createOutputProviderType to createReadOnlyProviderType aligns perfectly with the provider's intended functionality as described in the comment on line 68: "exposing the resolved configuration values (read-only)". This makes the provider's read-only nature explicit in its definition rather than just in documentation.

packages/utils/src/toposort/toposort.unit.test.ts (6)

1-8: Well-structured imports and dependencies.

The imports are properly organized, with test framework utilities first, followed by the module under test.


9-39: Excellent helper function implementation.

The expectOrder helper function is well-designed to verify that the sorted output respects all dependencies. It meticulously checks that for each edge, the source node appears before the target node in the sorted output, with clear error messages for diagnostics.


40-109: Comprehensive test cases for happy paths.

These tests thoroughly cover the expected behaviors of the toposort function, including:

  • Empty graphs
  • Single node graphs
  • Linear chains (with both string and number nodes)
  • Multiple paths with branching dependencies
  • Disconnected components
  • Nodes with no edges

The tests are well-organized, with clear expectations and validations using both exact equality and the custom expectOrder helper.


113-180: Thorough error handling tests for cyclical dependencies.

The test cases appropriately verify that the function throws the correct error type (ToposortCyclicalDependencyError) with the expected cycle path for various cycle scenarios:

  • Simple cycles between two nodes
  • Longer cycles involving multiple nodes
  • Self-loops

The tests check both the error type and the detailed error information, ensuring complete validation of error behavior.


182-210: Robust validation of unknown node error handling.

These tests properly verify that the function throws ToposortUnknownNodeError when nodes referenced in edges don't exist in the input list. Testing both unknown source and target nodes ensures complete coverage of this error condition.


212-238: Excellent edge case handling.

The final tests confirm the function's ability to handle:

  1. Object nodes using reference equality
  2. Duplicate edges gracefully

These edge cases are important for robust implementation and show attention to detail in the testing strategy.

packages/sync/src/utils/create-config-provider-task.ts (2)

17-19: Import replacement aligns with provider refactoring.

Adding createReadOnlyProviderType to replace the removed createOutputProviderType is consistent with the PR objective of refactoring output providers to read-only providers.


100-102: Provider type change correctly implements read-only behavior.

Changing from createOutputProviderType to createReadOnlyProviderType aligns with the provider's intended functionality as described in the comment on line 60: "exposing the resolved configuration values (read-only)". This change is consistent with the similar modification in create-config-provider-task-with-info.ts, showing a systematic approach to this refactoring.

packages/fastify-generators/src/generators/prisma/prisma/index.ts (2)

18-19: Import replacement aligns with provider refactoring.

Adding createReadOnlyProviderType to replace the removed createOutputProviderType is consistent with the PR objective of refactoring output providers to read-only providers.


66-67: Appropriate provider type for read-only operations.

Changing prismaOutputProvider to use createReadOnlyProviderType is appropriate since the PrismaOutputProvider interface only defines getter methods that retrieve information without modifying state. This aligns perfectly with making it a read-only provider and follows the consistent pattern of provider refactoring across the codebase.

packages/fastify-generators/src/generators/yoga/yoga-plugin/index.ts (3)

21-21: Good refactoring: Using read-only providers instead of output providers

This change aligns with the PR objective of changing output providers to read-only providers, which generally improves immutability and reduces potential side effects.


35-35: Path updated for loggerServiceProvider import

The import path for loggerServiceProvider has been updated to point to a more specific location, which helps with better code organization and clarity.


78-80: Provider type changed to read-only

The yogaPluginSetupProvider has been updated to use createReadOnlyProviderType instead of createOutputProviderType, which enforces immutability of the provider data.

packages/core-generators/src/renderers/typescript/templates/creators.ts (1)

1-1: Enhanced template function with import providers support

The tsCodeFileTemplate function has been enhanced with a new generic type parameter TImportProviders that allows for better type-checking and integration with the new TsImportMap system. This change improves type safety while maintaining backward compatibility by providing a default empty record.

Also applies to: 13-19

packages/fastify-generators/src/generators/core/config-service/index.ts (4)

29-32: Added new import map providers

New imports for configServiceImportsProvider and createConfigServiceImportMap have been added, which aligns with the PR objective of introducing the new TsImportMap system for better import handling.


84-87: Updated exports to include configServiceImports

The exports object has been extended to include configServiceImports, making the import map provider available at the project scope, which is necessary for the new import handling system.


124-127: Added configServiceImports provider

The implementation properly configures the import map for the config service, specifying the service path. This creates a centralized way to manage imports for the config service throughout the codebase.


210-210: Re-exported configServiceImportsProvider

The module re-exports the configServiceImportsProvider to make it available for use in other modules. This is good practice for encapsulation while providing necessary functionality to external modules.

packages/fastify-generators/src/generators/prisma/prisma-crud-service/index.ts (1)

7-7: Converted output provider to read-only provider

The prismaCrudServiceProvider is now created using createReadOnlyProviderType instead of createOutputProviderType. This change:

  1. Aligns with the PR's objective of refactoring output providers to use read-only providers
  2. Enforces immutability which reduces potential side effects
  3. Makes the code more robust and predictable

This is part of a consistent pattern across multiple files in this PR.

Also applies to: 32-32

packages/sync/src/runner/tests/dependency-entry.test-helper.ts (1)

1-46: Well-designed helper functions for test dependency creation

This new file introduces clean, well-structured helper functions for creating test dependency entries. The code follows good practices with proper type annotations, clear function names, and effective use of the nullish coalescing operator for default values.

The functions provide a consistent interface for creating different types of dependency entries:

  • createDependencyEntry as the base function
  • createReadOnlyDependencyEntry for read-only entries
  • createOutputDependencyEntry for output entries (which are inherently read-only)

This approach will improve test readability and maintainability across the codebase.

packages/sync/src/runner/generator-runner.unit.test.ts (5)

17-19: Import update aligned with provider type refactoring

The import now correctly includes createReadOnlyProviderType instead of the removed createOutputProviderType, aligning with the PR's objective of refactoring output providers to use read-only providers.


221-224: Output provider replaced with read-only provider

The change from createOutputProviderType to createReadOnlyProviderType correctly implements the new provider model. This test now validates that read-only providers work properly in the context previously used for output providers.


340-347: Updated provider types in phased task execution test

Both mainOutputProviderType and phase1OutputProviderType are now correctly created using createReadOnlyProviderType instead of createOutputProviderType, maintaining the test's functionality while conforming to the new provider model.


461-462: Updated error message to reflect new provider model

The error message now correctly references "read-only" status rather than "output" status, accurately reflecting the new requirement that dependencies from previous phases must be read-only.


620-623: Updated provider type in dynamic tasks test

The dynamic task test now correctly uses createReadOnlyProviderType instead of createOutputProviderType, aligning with the updated provider model.

packages/core-generators/src/renderers/typescript/templates/types.ts (2)

1-3: Added imports for new TypeScript import handling system

The new imports for ProviderType and TsImportMapProvider support the TsImportMap system being introduced in this PR, enabling stronger typing for import maps.


19-38: Enhanced TsCodeFileTemplate to support import map providers

The interface has been expanded with:

  1. A new generic type parameter TImportMapProviders with a sensible default
  2. A new optional importMapProviders property with clear documentation

This enhancement allows for specifying import map providers while maintaining backward compatibility, supporting the new import handling system without breaking existing code.

packages/sync/src/runner/dependency-sort.ts (3)

1-1: Updated toposort import source

The import has been changed from default to named import from '@halfdomelabs/utils', reflecting the reorganization of utility functions.


84-84: Updated toposort function call

The call to toposort has been updated to match its new signature as a named import, keeping the functionality consistent.


53-55:

Details

✅ Verification successful

Simplified property access for dependency metadata

The code now directly accesses isOutput and isReadOnly properties from the dependent object instead of using optional chaining and nullish coalescing. Ensure that these properties are always defined on the dependent object to avoid potential undefined errors.


🏁 Script executed:

#!/bin/bash
# Check if EntryDependencyRecord always defines isOutput and isReadOnly properties

echo "Checking EntryDependencyRecord interface definition..."
rg -A 10 "interface EntryDependencyRecord" packages/sync/src/

Length of output: 894


Verified Dependency Property Access is Safe

The change to directly access dependent.isOutput and dependent.isReadOnly is valid because the EntryDependencyRecord interface (defined in packages/sync/src/runner/dependency-map.ts) guarantees that both properties exist as booleans. No further issues were found.

  • Confirmed that the EntryDependencyRecord interface defines isOutput and isReadOnly as boolean.
  • No additional refactor is necessary.
packages/core-generators/src/renderers/typescript/import-maps/ts-import-map.ts (3)

9-13: Nice type-safe schema creation function.

This function provides a simple but effective way to enforce type safety on import schemas without adding runtime overhead.


15-21: LGTM: Well-structured input type definition.

The type allows for both simple string paths and objects with source properties, providing flexibility in how imports are defined.


69-74: LGTM: Provider creation function is simple and effective.

This function composes nicely with createTsImportMap to create a provider for the import map schema.

packages/sync/src/runner/dependency-map.unit.test.ts (4)

17-17: Good refactoring to support readOnly providers.

The transition from output providers to readOnly providers is well-handled with proper imports and type creation.

Also applies to: 23-27, 35-35


112-116: Improved test readability with helper functions.

Using the helper functions like createDependencyEntry and createReadOnlyDependencyEntry improves code consistency and readability compared to inline objects.

Also applies to: 194-197, 249-252, 255-258, 461-464, 467-470


538-539: Successfully migrated providers to readOnly pattern.

All output providers have been effectively migrated to readOnly providers, maintaining the same functionality while aligning with the new pattern.

Also applies to: 549-549, 562-565, 579-580, 586-587, 600-603, 639-640, 647-648, 672-675, 750-751, 768-769, 782-783, 807-810, 816-819, 826-829, 864-867, 926-929, 935-938, 975-976, 992-995


608-608: Terminology updated from "non-output provider" to "mutable provider".

The error message and test description have been updated to reflect the new terminology, which is more accurate and descriptive.

Also applies to: 625-625

packages/fastify-generators/src/generators/pothos/pothos/index.ts (1)

25-25: Successfully migrated Pothos providers to readOnly pattern.

The Pothos generator has been properly updated to use createReadOnlyProviderType instead of output providers, maintaining the same structure and type definitions.

Also applies to: 54-58, 68-70

packages/core-generators/src/renderers/typescript/import-maps/transform-ts-imports-with-map.ts (1)

4-18: Well-documented function with comprehensive JSDoc.

The JSDoc comment clearly explains the function's purpose, behavior, and parameters, making it easy for other developers to understand and use.

packages/sync/src/runner/dependency-sort.unit.test.ts (8)

5-5: Adopted read-only provider.

Using createReadOnlyProviderType for the output provider aligns with the new read-only approach. Ensure the name "output-provider" is still appropriate, given it's now read-only.


8-12: Centralized dependency creation.

Switching to createDependencyEntry, createOutputDependencyEntry, and createReadOnlyDependencyEntry standardizes how dependencies are defined, reducing code duplication and improving clarity.


29-34: Use of createDependencyEntry.

These lines correctly replace inline dependency objects with function calls, making the test setup more consistent.


37-44: Consistent dependency usage.

Again, good consistency in applying createDependencyEntry for building the dependency graph.


95-99: Correct usage of createOutputDependencyEntry.

This mapping ensures consumer tasks depend on the producer’s output. The approach is clear and straightforward.


140-149: Multiple dependency definitions.

Combining createOutputDependencyEntry and createDependencyEntry in one dependency map is well-handled. No issues here.


181-185: Read-only dependencies.

Using createReadOnlyDependencyEntry for the consumer matches the test’s intention. No issues found.


232-246: Complex dependency chain.

These entries correctly showcase mixed provider types (outputDependencyEntry, createDependencyEntry, createReadOnlyDependencyEntry). The test thoroughly covers multi-tier dependencies.

packages/utils/src/toposort/toposort.ts (3)

1-10: Custom cyclical dependency error class.

Excellent job encapsulating cycle path details in ToposortCyclicalDependencyError. This makes debugging cycles more straightforward.


12-19: Custom unknown node error class.

ToposortUnknownNodeError neatly isolates missing-node issues. This separation from cyclical errors improves error specificity.


21-42: Outgoing edges creation with validation.

The makeOutgoingEdges function is well-structured, ensuring non-existent nodes are caught early. Good robust error checks.

packages/fastify-generators/src/generators/core/logger-service/logger-service.generator.ts (5)

13-13: Added typescriptFileProvider to dependencies.

This aligns the generator tasks with the newly introduced read-only TypeScript file handling system. No concerns here.


25-28: Importing logger service import map artifacts.

Bringing in createLoggerServiceImportMap and loggerServiceImportsProvider clarifies how logger imports are handled.


67-67: Provider dependency update.

Ensuring typescriptFileProvider is part of the dependencies is crucial for file template operations. Looks good.


72-74: New output for logger service imports.

Exporting loggerServiceImports helps decouple import management from the main logger provider logic.


158-159: Re-exporting the imports provider.

Re-exporting loggerServiceImportsProvider aligns with the overall pattern of making key providers available at the generator's entry points.

packages/sync/src/runner/dependency-map.ts (11)

10-10: Use of ProviderExport type
The introduction of ProviderExport at line 10 looks consistent with the new logic handling provider exports. No immediate concerns here.


20-20: Updated providers map structure
Changing providers to store an object { taskId: string; isOutput: boolean } rather than a simple string reference clarifies usage context. This can help in subsequent logic (e.g., checking for duplicates, determining output status).


36-39: Nested record type for EntryDependencyMap
Using a nested Record<string, Record<string, EntryDependencyRecord | null | undefined>> is a succinct approach for organizing dependencies. Verify that passing null | undefined is intentional and consistently handled throughout the codebase.


59-59: Filtering for non-read-only outputs
This filter ensures that any task outputs that are not read-only are flagged as invalid. This enforces the requirement that outputs must strictly be read-only, preventing configuration mistakes.


63-63: Error message clarity
The error text clearly identifies the invalid provider outputs. The usage of invalidTaskOutputs.map((output) => output.name) is helpful to inform the user exactly which outputs are invalid.


68-71: addTaskExport helper function
The helper cleanly encapsulates adding exports while respecting isOutput. Good job keeping the parameters minimal and explicit.


103-106: Storing isOutput in the provider map
This approach effectively captures output status for downstream decisions. The chosen naming is consistent with the property name from the function parameter.


153-154: Destructuring isReadOnly & dependency options
Destructuring is straightforward. Ensure the upstream code always populates these fields (like normalizedDep.options) to avoid possible undefined property scenarios.


170-172: Resolving providers from generatorIdToScopesMap
The condition checks if a matching provider is found only within the relevant parent scope. This helps keep dependencies from leaking outside their intended scope.


174-174: Error on unresolvable dependency
Throwing here avoids incorrectly setting up the task with incomplete provider references. Looks correct.


195-196: Combining isOutput with isReadOnly
Bundling both states into the final dependency record is logical. Confirm that the rest of the pipeline correctly handles scenarios where isOutput and isReadOnly might conflict.

packages/core-generators/src/renderers/typescript/import-maps/types.ts (7)

1-1: Importing TsImportDeclaration
The usage of a separate import for TsImportDeclaration helps keep the code modular. No issues found here.


16-16: TsImportMapSchema
A simple record type that ties string keys to TsImportMapSchemaEntry. Straightforward and easy to reason about.


18-28: TsImportMapEntry interface
The approach to differentiate declaration(...) and typeDeclaration(...) is neat. The generic constraint IsTypeOnly extends boolean | undefined is a clever way to produce a compile-time error (never) if isTypeOnly is always true. This design is advanced but very useful for type integrity.


30-30: Definition of TsImportMap
This record of TsImportMapEntry provides a direct mapping from string keys to their imported declarations. No issues found.


32-34: InferTsImportMapFromSchema
Inferring a map entry from TsImportMapSchema ensures consistency throughout the code. This strongly enforces the typed relationship between schema definitions and actual import map entries.


36-38: TsImportMapProvider interface
Encapsulating the entire map under importMap is a clean pattern for providers. This design is easy to integrate with external code.


40-41: Combining schema with provider
TsImportMapProviderFromSchema neatly composes the inferred map with the provider to produce a typed provider object. This is a well-structured approach.

packages/fastify-generators/src/generators/core/error-handler-service/index.ts (7)

11-11: Refactoring to use typescriptFileProvider
Bringing in typescriptFileProvider helps unify file operations under the same interface for generating code. This approach is consistent across the codebase.


22-22: Replacing direct configServiceProvider with configServiceImportsProvider
Switching to a read-only provider for config imports indicates a shift away from mutable config usage. This can reduce side effects and ensure immutability of shared resources.


24-25: Reorganized imports for logger & error handler template
Using loggerServiceProvider from logger-service.generator.js and referencing errorHandlerPluginFileTemplate from ./generated/templates.js centralizes template logic. This makes future maintenance easier.


70-70: Adding configServiceImports as a task dependency
Explicitly listing configServiceImports indicates the generator relies on specialized config import functionality. This is a more modular approach than pulling in the entire config service.


74-74: Introducing typescriptFile for file generation tasks
Depending on typescriptFileProvider clarifies that this step involves writing TypeScript files, aligning with the read-only provider pattern.


80-85: Expanded parameters in run
The new signature fetches configServiceImports and typescriptFile. This is consistent with the shift to read-only providers. It also declutters the method by removing less relevant provider calls.


124-132: Using typescriptFile.writeTemplatedFile with importMapProviders
This is a clean integration of the new approach—using errorHandlerPluginFileTemplate while injecting configService imports. It further showcases how read-only providers unify the injection of external resources without side effects.

packages/sync/src/providers/providers.ts (4)

68-68: Confirm backward compatibility for ProviderDependency.isReadOnly.

This field has changed from being optional to mandatory. Please verify that all existing references to ProviderDependency instances are updated so they explicitly configure or handle isReadOnly.


105-105: Align ProviderExport.isReadOnly with final spec.

Similar to the above dependency property, this export property is now always true or false. Ensure consumers of ProviderExport expect it to be strictly defined.


157-163: Check defaults for isReadOnly logic.

Here, isReadOnly is defaulted to false when the user doesn’t specify otherwise. Confirm that this default strategy won’t lead to confusion for tasks where output usage is not intended, or that callers definitely override it if they need read-only behavior.

Also applies to: 193-193


212-214: New createReadOnlyProviderType function looks solid.

This utility ensures a provider is always read-only. There are no obvious issues, but you might consider whether any further checks are needed to ensure an already read-only provider isn’t re-wrapped or forced into another read-only instance redundantly.

Also applies to: 216-216

packages/core-generators/src/renderers/typescript/renderers/file.ts (4)

1-1: New imports provide clarity around the use of TsImportMap.

Importing TsImportMap, TsImportMapProvider, and transformTsImportsWithMap integrates seamlessly with the rest of the file. No apparent issues found here.

Also applies to: 8-8, 18-18


49-50: mergeImportsAndHoistedFragments now supports import maps.

By passing importMaps: Map<string, TsImportMap> and transforming the existing imports, the solution appears clean. Keep an eye on performance if the number of import maps grows large, though for most scenarios this should be efficient.

Also applies to: 58-62


117-126: Extended renderTsCodeFileTemplate with TImportMapProviders.

Allowing a generic for the import-map providers improves flexibility and type-safety. Confirm that all call sites now pass importMapProviders when needed or else handle them gracefully if defaulted.


140-140: Conditional return and import map providers map construction.

  1. The early return (line 140) avoids overhead when no imports, fragments, or providers are relevant, which is a helpful optimization.
  2. The creation of importMapProvidersMap ensures each provider has the required importMap property, throwing if not.
  3. Passing importMapProvidersMap to mergeImportsAndHoistedFragments is well-structured.

Everything looks consistent in error handling and usage.

Also applies to: 154-164, 172-173

packages/core-generators/src/generators/node/typescript/index.ts (3)

3-5: Imports reorganize references to GeneratorTaskOutputBuilder, ProviderType, and InferImportMapProvidersFromProviderTypeMap.

This reorganization is coherent and aligns with changes in the rest of the codebase. No concerns here.

Also applies to: 21-21


93-105: WriteTemplatedFilePayload interface additions add clarity.

Adding id and importMapProviders clarifies how generated templates are identified and how map providers are injected. Make sure the rest of the pipeline or any preexisting usage of WriteTemplatedFilePayload is updated accordingly.


109-118: Signature changes for writeTemplatedFile effectively support import maps.

Requiring TImportMapProviders in the payload ensures the function can handle these providers robustly. This is a welcome enhancement for typed usage.

@kingston kingston merged commit 5fc4621 into main Apr 7, 2025
7 checks passed
@kingston kingston deleted the kingston/eng-603-introduce-new-system-for-passing-around-imports-between branch April 7, 2025 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants