feat: refactor runtime data flow, improve hot-reloading, re-export indexer modules, add sourcemaps, option to override clientOptions in indexer #177
Conversation
…@apibara/indexer` dependency
📝 WalkthroughWalkthroughThis update introduces source map support across all packages by enabling source map generation in build configurations and updating related prerelease metadata files. The CLI runtime data flow is refactored to centralize runtime and preset configuration handling via environment variables and helper utilities. Several new modules are added for modular imports, and import paths throughout example and generated files are updated to use unscoped package names. The configuration and hot reloading logic are revised to improve runtime config merging, preset handling, and process management. Deprecated or redundant files and plugins are removed, and the package exports and TypeScript configuration are updated to reflect the new module structure. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI_User
participant CLI_Process
participant EnvHelper
participant IndexerModule
CLI_User->>CLI_Process: Run CLI command (dev/start)
CLI_Process->>EnvHelper: getRuntimeDataFromEnv()
EnvHelper-->>CLI_Process: {preset, processedRuntimeConfig}
CLI_Process->>IndexerModule: createIndexer({indexerName, processedRuntimeConfig, preset})
IndexerModule-->>CLI_Process: Indexer instance (uses processed config)
Possibly related PRs
Suggested reviewers
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (3)
🧰 Additional context used🧬 Code Graph Analysis (1)packages/indexer/src/indexer.ts (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (12)
packages/indexer/build.config.ts (1)
16-16: Consider including inline sources in your source maps
To provide even richer debugging information—including original TypeScript source content—you might extend this setting with aninlineSourcesflag (if supported by your build toolchain) or configure Rollup’soutput.sourcemapoptions accordingly. This can eliminate the need to fetch.tsfiles separately when inspecting stack traces.packages/starknet/build.config.ts (1)
8-8: Enable source maps for improved debugging
The addition ofsourcemap: trueensures that your compiled output emits sourcemaps, which will greatly aid in tracing errors back to the original TypeScript.
Consider also addinginlineSources: trueto embed the TS sources directly in the map files, further enhancing the debugging experience in IDEs and browser devtools.change/@apibara-evm-1fd2380c-16c6-4640-acf7-64a2f40baf8c.json (1)
5-5: Check author email formatting.The
"jadejajaipal5@gmail.com". Ensure this is the correct address for release notifications. If your organization uses a centralized alias (e.g.,releases@apibara.com), consider using that instead.change/@apibara-plugin-mongo-add18c13-4892-47e9-b4c3-5e666ce99996.json (3)
3-3: Align the comment with commit/message conventions
The"comment"field is free‑form metadata but should stay consistent with the monorepo’s commit message guidelines (e.g.,build: add sourcemaps to all packages). Consider using imperative tense and a concise prefix if other prerelease files follow a different pattern.
5-5: Validate author email visibility
The"email"field contains PII that will be published in release metadata. Verify that this address is correct and that exposing it aligns with project policy.
7-8: Ensure JSON formatting and trailing newline
This file is valid JSON, but please confirm there’s a single newline at EOF and no trailing commas to maintain consistency with other metadata files.packages/plugin-sqlite/build.config.ts (1)
8-8: Optional: Generate declaration maps
To further aid debugging of type definitions, consider enablingdeclarationMap: trueso that.d.ts.mapfiles are produced alongside your.d.tsdeclarations:export default defineBuildConfig({ entries: ["./src/index.ts"], clean: true, outDir: "./dist", declaration: true, sourcemap: true, + declarationMap: true, rollup: { emitCJS: true, }, });packages/cli/src/core/config/resolvers/runtime.resolver.ts (1)
26-28: Consider adding more robust JSON parsing error handling.While the overall error handling is good, this specific JSON parsing operation could benefit from explicit error handling since it relies on user-provided input.
- const userEnvRuntimeConfig = JSON.parse( - process.env[USER_ENV_APIBARA_RUNTIME_CONFIG] ?? "{}", - ); + let userEnvRuntimeConfig = {}; + try { + if (process.env[USER_ENV_APIBARA_RUNTIME_CONFIG]) { + userEnvRuntimeConfig = JSON.parse( + process.env[USER_ENV_APIBARA_RUNTIME_CONFIG] + ); + } + } catch (error) { + throw new Error( + "Failed to parse runtime config from environment variable", + { cause: error } + ); + }packages/cli/src/common/helper.ts (4)
52-52: Use deep cloning for runtime configUsing the spread operator (
{ ...runtimeConfig }) creates a shallow copy which may lead to unexpected behavior ifruntimeConfigcontains nested objects that are later modified.- let _runtimeConfig: Record<string, unknown> = { ...runtimeConfig }; + // Create a deep clone to avoid unintentional mutations of nested objects + let _runtimeConfig: Record<string, unknown> = JSON.parse(JSON.stringify(runtimeConfig || {}));Alternatively, you could use a deep cloning utility if available in your codebase.
34-40: Document function return type in JSDocThe function documentation explains priorities well but doesn't describe what the function returns. Adding the return type information would improve the documentation.
/** * Get the merged runtime config from the user env overrided runtime config, presets and defaults. * Priority (Highest to lowest): * 1. User env overrided runtime config * 2. Preset * 3. Defaults + * + * @returns {Record<string, unknown>} The merged runtime configuration object */
73-83: Redundant error handling for userEnvRuntimeConfigThe
userEnvRuntimeConfighas already been parsed from JSON in thegetRuntimeDataFromEnv()function, so the try/catch block here is unnecessary. The error would have been caught earlier.if (userEnvRuntimeConfig) { - try { - // Environment runtime config applied - _runtimeConfig = defu(userEnvRuntimeConfig, _runtimeConfig); - } catch (error) { - throw new Error( - "Failed to parse runtime config from process.env.APIBARA_RUNTIME_CONFIG. Please ensure it is a valid JSON string.", - { cause: error }, - ); - } + // Environment runtime config applied + _runtimeConfig = defu(userEnvRuntimeConfig, _runtimeConfig); }
1-8: Import "defu" type for better type safetyThe
defufunction is imported without its type information, which might lead to issues with TypeScript type checking.-import defu from "defu"; +import defu, { type Defu } from "defu";This depends on whether the
defupackage exports its types. If it does, importing them would improve type safety in your code.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (52)
change/@apibara-beaconchain-6446ef46-637b-4b6b-96df-72f561286812.json(1 hunks)change/@apibara-evm-1fd2380c-16c6-4640-acf7-64a2f40baf8c.json(1 hunks)change/@apibara-indexer-3b0c9ba4-39a3-4c10-80c2-3efc2defc167.json(1 hunks)change/@apibara-plugin-drizzle-e06d17ff-fbbe-492e-a3b6-28842772e7db.json(1 hunks)change/@apibara-plugin-mongo-add18c13-4892-47e9-b4c3-5e666ce99996.json(1 hunks)change/@apibara-plugin-sqlite-05d6412f-e9b4-436c-b03b-a19f6e801197.json(1 hunks)change/@apibara-protocol-c2f956f6-1714-4f67-99f3-dc5af63bcee1.json(1 hunks)change/@apibara-starknet-6e5b2085-16df-4ba6-9802-c83b2f744259.json(1 hunks)change/apibara-59d66024-b9f5-4907-8b4e-f668cc87c247.json(1 hunks)examples/cli-drizzle/indexers/1-evm.indexer.ts(1 hunks)examples/cli-drizzle/indexers/2-starknet.indexer.ts(1 hunks)examples/cli-drizzle/indexers/3-starknet-factory.indexer.ts(1 hunks)examples/cli-drizzle/test/ethereum.test.ts(1 hunks)examples/cli-drizzle/test/starknet.test.ts(1 hunks)packages/beaconchain/build.config.ts(1 hunks)packages/cli/build.config.ts(3 hunks)packages/cli/package.json(2 hunks)packages/cli/src/cli/commands/dev.ts(4 hunks)packages/cli/src/cli/commands/start.ts(1 hunks)packages/cli/src/common/constants.ts(1 hunks)packages/cli/src/common/helper.ts(1 hunks)packages/cli/src/common/index.ts(1 hunks)packages/cli/src/core/apibara.ts(1 hunks)packages/cli/src/core/build/dev.ts(1 hunks)packages/cli/src/core/config/loader.ts(1 hunks)packages/cli/src/core/config/resolvers/preset.resolver.ts(0 hunks)packages/cli/src/core/config/resolvers/runtime.resolver.ts(1 hunks)packages/cli/src/core/config/update.ts(1 hunks)packages/cli/src/create/constants.ts(0 hunks)packages/cli/src/create/templates.ts(1 hunks)packages/cli/src/hooks/useRuntimeConfig.ts(1 hunks)packages/cli/src/indexer/index.ts(1 hunks)packages/cli/src/indexer/plugins.ts(1 hunks)packages/cli/src/indexer/testing.ts(1 hunks)packages/cli/src/indexer/vcr.ts(1 hunks)packages/cli/src/rolldown/config.ts(0 hunks)packages/cli/src/rolldown/plugins/config.ts(0 hunks)packages/cli/src/runtime/dev.ts(3 hunks)packages/cli/src/runtime/internal/app.ts(2 hunks)packages/cli/src/runtime/internal/helper.ts(0 hunks)packages/cli/src/runtime/project-info.ts(2 hunks)packages/cli/src/runtime/start.ts(2 hunks)packages/cli/src/types/config.ts(1 hunks)packages/cli/src/types/virtual/config.d.ts(0 hunks)packages/cli/tsconfig.json(2 hunks)packages/evm/build.config.ts(1 hunks)packages/indexer/build.config.ts(1 hunks)packages/plugin-drizzle/build.config.ts(1 hunks)packages/plugin-mongo/build.config.ts(1 hunks)packages/plugin-sqlite/build.config.ts(1 hunks)packages/protocol/build.config.ts(1 hunks)packages/starknet/build.config.ts(1 hunks)
💤 Files with no reviewable changes (6)
- packages/cli/src/create/constants.ts
- packages/cli/src/runtime/internal/helper.ts
- packages/cli/src/rolldown/plugins/config.ts
- packages/cli/src/types/virtual/config.d.ts
- packages/cli/src/rolldown/config.ts
- packages/cli/src/core/config/resolvers/preset.resolver.ts
🧰 Additional context used
🧬 Code Graph Analysis (6)
packages/cli/src/core/config/loader.ts (2)
packages/cli/src/core/config/resolvers/paths.resolver.ts (1)
resolvePathOptions(4-14)packages/cli/src/core/config/resolvers/runtime.resolver.ts (1)
runtimeConfigResolver(11-44)
packages/cli/src/core/apibara.ts (2)
packages/cli/src/types/config.ts (1)
ApibaraDynamicConfig(44-47)packages/cli/src/core/config/update.ts (1)
updateApibaraConfig(4-13)
packages/cli/src/hooks/useRuntimeConfig.ts (2)
packages/cli/src/types/runtime.ts (1)
ApibaraRuntimeConfig(1-1)packages/cli/src/common/constants.ts (1)
ENV_INTERNAL_APIBARA_PROCESSED_RUNTIME(4-5)
packages/cli/src/runtime/project-info.ts (2)
packages/cli/src/common/helper.ts (2)
getRuntimeDataFromEnv(10-32)getProcessedRuntimeConfig(41-86)packages/cli/src/runtime/internal/app.ts (2)
availableIndexers(22-22)createIndexer(24-97)
packages/cli/src/common/helper.ts (1)
packages/cli/src/common/constants.ts (5)
ENV_INTERNAL_APIBARA_PROCESSED_RUNTIME(4-5)ENV_INTERNAL_APIBARA_PRESET(2-2)ENV_INTERNAL_APIBARA_PRESETS(3-3)ENV_INTERNAL_APIBARA_RUNTIME(1-1)USER_ENV_APIBARA_RUNTIME_CONFIG(6-6)
packages/cli/src/core/config/resolvers/runtime.resolver.ts (3)
packages/cli/src/types/config.ts (1)
ApibaraOptions(57-108)packages/cli/src/common/constants.ts (5)
ENV_INTERNAL_APIBARA_RUNTIME(1-1)ENV_INTERNAL_APIBARA_PRESET(2-2)ENV_INTERNAL_APIBARA_PRESETS(3-3)USER_ENV_APIBARA_RUNTIME_CONFIG(6-6)ENV_INTERNAL_APIBARA_PROCESSED_RUNTIME(4-5)packages/cli/src/common/helper.ts (1)
getProcessedRuntimeConfig(41-86)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: test
🔇 Additional comments (83)
packages/evm/build.config.ts (1)
8-8: Enable source map generation
Addingsourcemap: trueensures that the build emits source maps for better debugging and stack traces. Please verify post-build that.mapfiles appear indist/and that your runtime or IDE correctly picks them up.packages/indexer/build.config.ts (1)
16-16: Enable source map generation for improved debugging
Addingsourcemap: trueensures that compiled output includes source maps, aligning with other packages in the monorepo and greatly aiding developers when troubleshooting or stepping through code in their editors or debuggers.packages/plugin-mongo/build.config.ts (1)
8-8: Enable source map generation for improved debugging
Addingsourcemap: trueto the build config is correct and consistent with the other packages, facilitating better traceability of original TypeScript sources during development and troubleshooting.change/@apibara-indexer-3b0c9ba4-39a3-4c10-80c2-3efc2defc167.json (1)
1-7: Approve prerelease metadata JSONThe JSON correctly specifies the prerelease configuration for
@apibara/indexer, including the release type, descriptive comment, package scope, author email, and patch-level change designation. No issues detected.packages/protocol/build.config.ts (1)
8-8: Enable source maps in build configuration
The addition ofsourcemap: truecorrectly activates source map generation for this package’s build, improving debugging and stack trace mapping. This change is consistent with the coordinated updates across other packages.change/@apibara-protocol-c2f956f6-1714-4f67-99f3-dc5af63bcee1.json (1)
1-7: Add prerelease metadata for sourcemaps patch
The new JSON file accurately declares a prerelease for@apibara/protocolwith the appropriate comment, email, and patch-level change type. It follows the established pattern for other packages’ metadata files.change/@apibara-plugin-sqlite-05d6412f-e9b4-436c-b03b-a19f6e801197.json (5)
2-2: Validate prerelease type
The"type"field is correctly set to"prerelease", matching the intended workflow for adding sourcemaps without bumping public APIs.
3-3: Confirm commit description
The"comment"accurately summarizes the change ("build: add sourcemaps to all packages") and adheres to conventional commit style.
4-4: Verify package name
The"packageName"is correctly specified as"@apibara/plugin-sqlite", aligning with the package being updated.
5-5: Ensure contact email accuracy
The"email"field is well‑formed. Please confirm this address is intended for release notifications.
6-6: Dependent change type is correct
Setting"dependentChangeType"to"patch"is appropriate, as sourcemap support is a build‐only enhancement that doesn’t affect public APIs.change/@apibara-evm-1fd2380c-16c6-4640-acf7-64a2f40baf8c.json (3)
2-3: Ensure consistency of prerelease metadata comment and type.The
typeis set to"prerelease", and thecommentfield accurately reflects the build change. Verify that this schema and messaging convention align with other packages’ prerelease metadata to maintain a unified release process.
4-4: VerifypackageNamematches the published package.The
packageNameis"@apibara/evm". Confirm this exactly matches the name declared in the correspondingpackage.jsonto avoid any publishing discrepancies.
6-6: Validate semantic version bump strategy.Using
"patch"fordependentChangeTypeis appropriate since adding sourcemaps is non-breaking. If any other user‐facing changes are introduced alongside this, consider updating to"minor".change/@apibara-plugin-mongo-add18c13-4892-47e9-b4c3-5e666ce99996.json (3)
2-2: Verify prerelease intent
The"type": "prerelease"flag drives release tooling behavior. Please confirm this change should indeed be published as a prerelease rather than a regular patch or minor release.
4-4: Confirm the package name
Ensure that"@apibara/plugin-mongo"exactly matches the published package identifier (including scope and hyphens). A mismatch here could lead to mis‑versioning or broken installs.
6-6: Dependent change type looks correct
The"dependentChangeType": "patch"designation is consistent for adding sourcemaps (non-breaking change). No action required if patch is intended.packages/plugin-sqlite/build.config.ts (1)
8-8: Enable source map generation
Addingsourcemap: trueensures that this package’s build will emit source maps, improving traceability and debugging and aligning with the other@apibara/*packages.packages/plugin-drizzle/build.config.ts (1)
8-8: Enable source map generation
Addingsourcemap: truealigns this package with the rest of the SDK to emit.mapfiles for improved debugging experience.change/@apibara-plugin-drizzle-e06d17ff-fbbe-492e-a3b6-28842772e7db.json (1)
1-7: Add prerelease metadata for sourcemaps
The new prerelease JSON correctly setstype,comment,packageName, anddependentChangeTypefor a patch-level prerelease. It matches the pattern used across other packages.packages/beaconchain/build.config.ts (1)
8-8: Enable source map generation
Addingsourcemap: truewill produce source maps for the beaconchain package, improving debugging capabilities. Please verify thatdefineBuildConfiginunbuildsupports thesourcemapoption (versussourcemaps) and that all other packages use the identical key for consistency.change/@apibara-beaconchain-6446ef46-637b-4b6b-96df-72f561286812.json (1)
1-7: Add prerelease metadata for patch-level release
The new JSON defines a patch‐level prerelease for@apibara/beaconchain, documenting the sourcemap addition, author email, and dependent change type. Ensure this file’s path and naming conform to the repository’s release metadata schema (e.g.,.changeset/or equivalent) so the release tooling picks it up correctly.change/@apibara-starknet-6e5b2085-16df-4ba6-9802-c83b2f744259.json (2)
1-7: Prerelease metadata looks correct.All required fields (
type,comment,packageName,dependentChangeType) are present and properly set for a patch-level prerelease, matching the intent to add sourcemaps to the@apibara/starknetpackage.
1-7:✅ Verification successful
Verify consistency across all prerelease metadata files.
To ensure the
typeandcommentfields are uniform across every@apibara/*prerelease in thechange/directory, you can run:
🏁 Script executed:
#!/bin/bash # Description: Validate that all prerelease JSONs share the same type and comment. set -e expected_type="prerelease" expected_comment="build: add sourcemaps to all packages" for file in change/@apibara-*.json; do type=$(jq -r '.type' "$file") comment=$(jq -r '.comment' "$file") pkg=$(jq -r '.packageName' "$file") if [[ "$type" != "$expected_type" || "$comment" != "$expected_comment" ]]; then echo "❌ Mismatch in $file (package=$pkg): type=$type, comment=$comment" exit 1 fi done echo "✅ All prerelease metadata files are consistent."Length of output: 4663
All prerelease metadata files are consistent
I ran the provided validation script against all
change/@apibara-*.jsonfiles and confirmed that each entry uses
- type:
prerelease- comment:
build: add sourcemaps to all packagesNo discrepancies were found—no further changes are needed.
examples/cli-drizzle/test/starknet.test.ts (1)
1-1: Import path updated to use unscoped proxy module
ThecreateVcrimport was correctly switched from the scoped package to the newapibara/testingproxy. Ensure thatapibara/testingis properly exported in the CLI package’spackage.jsonunder theexportsfield so this resolves at runtime.examples/cli-drizzle/test/ethereum.test.ts (1)
1-1: AligncreateVcrimport with new proxy module
The import forcreateVcrnow correctly points toapibara/testing. Just double‑check that the CLI package exports this subpath so Vitest can locate it without issues.examples/cli-drizzle/indexers/3-starknet-factory.indexer.ts (1)
2-3: Switched to unscoped indexer and plugin imports
The lines importingdefineIndexeranduseLoggerfromapibara/indexerandapibara/pluginsare correct following the new proxy modules. Verify that these paths are declared underexportsin the CLI package’s manifest.examples/cli-drizzle/indexers/1-evm.indexer.ts (2)
3-3: Proxy import fordefineIndexerapplied
The import ofdefineIndexerfromapibara/indexerreplaces the old scoped path. Confirm thatapibara/indexeris exposed by the CLI package.
10-10: Proxy import foruseLoggerapplied
UpdateduseLoggerto come fromapibara/plugins. Make sure the CLI package’sexportsinclude this subpath to avoid resolution errors.change/apibara-59d66024-b9f5-4907-8b4e-f668cc87c247.json (1)
1-7: Prerelease metadata is in place
The new prerelease descriptor correctly captures the CLI refactor’s intent, package name, and change type. No issues spotted in the JSON structure.packages/cli/src/indexer/testing.ts (1)
1-2: Clean and consistent module re-export patternThis re-export follows the same pattern as the other new module exports in the
/indexerdirectory, creating a consistent and unified import experience for consumers.examples/cli-drizzle/indexers/2-starknet.indexer.ts (1)
4-4: Import paths correctly updated to use the new module structureThe import paths have been properly updated from scoped packages (
@apibara/indexerand@apibara/indexer/plugins) to unscoped packages (apibara/indexerandapibara/plugins), aligning with the new re-export module structure.Also applies to: 7-7
packages/cli/src/cli/commands/start.ts (2)
53-53: Simplified CLI argument handlingThe conditional inclusion of the
--presetargument is removed, aligning with the new approach of using environment variables for runtime configuration and preset handling instead of CLI arguments.
61-65: More appropriate log levelChanged from
logtoinfo, which is more semantically correct for process exit notifications.packages/cli/src/common/index.ts (1)
1-2: Clean module structure for common utilitiesThis index file effectively centralizes access to the new runtime configuration helpers and constants, creating a clear entry point for these utilities.
packages/cli/src/indexer/plugins.ts (1)
1-1: Well-structured module re-exportThis re-export pattern improves the developer experience by allowing users to import from
apibara/pluginsinstead of@apibara/indexer/plugins, simplifying import paths while maintaining access to all indexer plugin functionality.packages/cli/src/indexer/index.ts (1)
1-1: Clean module re-export patternThis re-export is part of the broader refactoring to provide simpler import paths. By re-exporting from
@apibara/indexer, you're creating a more developer-friendly API that maintains all functionality while simplifying imports.packages/cli/src/hooks/useRuntimeConfig.ts (1)
1-1: Good refactoring using centralized constantsReplacing the hardcoded environment variable string with a constant from a centralized location improves maintainability and reduces the risk of typos or inconsistencies across the codebase.
Also applies to: 5-7
packages/cli/src/core/build/dev.ts (1)
105-106: Appropriate exclusion pattern with clear explanationAdding this ignore pattern for apibara configuration files is a good optimization since these changes are already handled by c12. This prevents duplicate handling of configuration changes and potential race conditions. The comment clearly explains the rationale.
packages/cli/src/indexer/vcr.ts (1)
1-1: Clean re-export of VCR moduleThis is a well-structured re-export that follows the pattern established for other indexer modules. This approach simplifies imports for consumers by providing a more direct path via the CLI package.
packages/cli/src/core/config/loader.ts (1)
10-13: Good addition of runtime config resolver to the config pipelineAdding the
runtimeConfigResolverto the config resolvers array ensures that runtime values are properly assigned to environment variables during the configuration loading process. The comment clearly explains the responsibility of this resolver.This change aligns well with the broader refactoring goal of centralizing runtime configuration management through environment variables rather than passing config objects directly.
packages/cli/src/core/apibara.ts (1)
31-32: Parameter rename improves clarityRenaming the parameter from
configtonewConfigprovides better clarity by distinguishing between the initial configuration and subsequent updates. This matches the parameter naming in theupdateApibaraConfigfunction.packages/cli/tsconfig.json (3)
7-7: Broader rootDir scope enables full package compilationChanging the
rootDirfrom "src" to "." expands TypeScript's compilation scope to include the entire package folder, which is necessary for the new module structure.
18-19: New path mappings support modular importsAdding path mappings for
apibara/runtimeandapibara/commonsupports the new modular structure and simplifies imports across the codebase. This aligns with the export updates in package.json.
22-22: Removal of include/exclude fieldsThe removal of the
includeandexcludefields is appropriate given the broaderrootDirscope. This allows TypeScript to use its default inclusion behavior based on therootDir.packages/cli/src/types/config.ts (1)
44-47: Expanded dynamic config to include preset-related propertiesThe
ApibaraDynamicConfigtype has been expanded to include not justruntimeConfigbut alsopresetandpresetsproperties. This change aligns with the PR's objective to improve hot-reloading by making preset configuration dynamically refreshable.packages/cli/src/create/templates.ts (1)
72-73: Updated import paths to use simplified unscoped package namesThe template now uses unscoped imports (
apibara/indexerandapibara/plugins) instead of scoped package imports (@apibara/indexerand@apibara/indexer/plugins). This implements the PR goal of re-exporting indexer modules through the CLI package.packages/cli/src/runtime/start.ts (3)
2-2: Added import for centralized runtime configuration handlingThe
getRuntimeDataFromEnvimport fromapibara/commonsupports the refactored runtime data flow for retrieving configuration from environment variables.
22-24: Refactored runtime configuration retrievalNow retrieving both
processedRuntimeConfigandpresetfrom environment variables usinggetRuntimeDataFromEnv()instead of directly accessing the preset from command arguments. This centralizes configuration management and improves hot-reloading capability.
27-31: Updated createIndexer call signature to use object parameterChanged from positional parameters to a named object parameter with
indexerName,processedRuntimeConfig, andpreset. This provides better clarity and flexibility for future parameter changes.packages/cli/src/runtime/dev.ts (3)
2-2: Added import for centralized runtime configuration handlingSimilar to start.ts, importing
getRuntimeDataFromEnvfromapibara/commonto support the refactored runtime data flow.
23-25: Refactored runtime configuration retrievalNow retrieving configuration data from environment variables, which aligns with the centralized runtime data flow approach implemented throughout the CLI.
43-47: Updated createIndexer call signature to use object parameterConsistent with the changes in start.ts, using a named object parameter for better code clarity and maintainability.
packages/cli/build.config.ts (6)
14-14: Well-structured modular organization with addition of "common" module.Adding the "common" module to the modules array helps organize shared code and utilities that will be used across different parts of the application, supporting the refactoring of runtime data flow.
29-29: Proper entry point configuration for the new common module.This correctly defines the entry point for the new "common" module that was added to the modules list above.
31-31: Good modularization by adding indexer module export.Adding the indexer module as a separate entry enables re-exporting from
@apibara/indexeras described in the PR objectives, improving the package structure and user experience.
33-33: Improved debugging with sourcemap support.Enabling sourcemaps across all packages will significantly improve the debugging experience, allowing developers to see the original TypeScript code in stack traces and debugging tools.
50-57: Good build performance monitoring with time logging.Adding build hooks to measure and log the build duration is a helpful development improvement that will make it easier to track build performance over time.
60-60: Improved type safety in the banner function.Explicitly typing the
fileNameparameter as a string improves type safety and code readability.packages/cli/src/core/config/update.ts (4)
2-2: Key dependency for the new runtime config resolution strategy.Importing the
runtimeConfigResolveris essential for the new approach to handling runtime configuration through environment variables rather than at build time.
6-6: Improved parameter naming for better code clarity.Changing the parameter name from
_configtonewConfigmakes the code more readable and self-documenting.
8-9: Core implementation of hot reload for runtime config.This change is central to addressing the PR's objective of fixing runtime config not updating correctly during development. By applying new config values to environment variables, it ensures they're available to restarted indexers.
11-12: Enhanced hot-reloading mechanism.Replaced the previous "rolldown:reload" hook with "dev:reload" to restart indexers with the updated runtime values, supporting the PR objective of improving the hot-reloading mechanism.
packages/cli/src/core/config/resolvers/runtime.resolver.ts (5)
1-8: Well-organized imports from the new common module.Importing constants and helper functions from the new common module maintains good separation of concerns and enables the centralized runtime config management intended by this PR.
11-14: Good function signature and initial variable extraction.The function correctly accepts a partial options object and extracts only the required properties needed for runtime configuration processing.
15-24: Proper environment variable persistence for configuration values.Setting the runtime config, preset, and presets as JSON-stringified environment variables creates a consistent way to pass these values to child processes and during hot reloads.
30-38: Well-structured final config processing and storage.This block effectively processes and merges configuration from multiple sources (base config, presets, and environment variables) and stores the result in an environment variable for consistent access.
39-43: Comprehensive error handling.The try-catch block with a descriptive error message and proper error cause handling will make debugging easier if issues arise with runtime configuration processing.
packages/cli/src/runtime/project-info.ts (4)
3-6: Good use of newly extracted common helper functions.Importing these helper functions from the common module helps maintain consistency in how runtime configuration is accessed and processed throughout the application.
37-39: Improved configuration source with environment variables.Using
getRuntimeDataFromEnv()aligns with the PR's objective to refactor runtime data flow and ensures consistent access to configuration across the application.
41-48: Well-structured preset processing.The code now properly processes runtime configuration for each preset by calling
getProcessedRuntimeConfigwith all relevant sources of configuration data, which is crucial for the improved hot-reloading mechanism.
51-55: Improved function call with named parameters.Using an object with named parameters for the
createIndexercall improves code readability and makes the API more resilient to future changes.packages/cli/package.json (2)
35-38: Good addition of new./commonexport pathAdding this export path for the common module is a good choice as it centralizes shared utilities and constants. This will make it easier to maintain consistent environment variable names and helpers across the codebase.
59-74: Well-structured re-exports from indexer packageThese new export paths effectively implement the PR objective of re-exporting modules from
@apibara/indexerthrough the CLI package. This modular approach allows users to import from cleaner paths likeapibara/indexerinstead of@apibara/indexer, improving developer experience while maintaining proper organization of the code.packages/cli/src/runtime/internal/app.ts (2)
24-38: Improved function signature with better parameter structureThe refactored function signature with a single object parameter is a good improvement. It makes the API more explicit and extensible, with clear JSDoc comments that document the purpose of each parameter.
57-57: Direct use of processed runtime configThis change correctly implements the refactored runtime data flow by directly using the externally provided
processedRuntimeConfiginstead of calculating it internally. This addresses the issue where runtime config values weren't updating correctly during development.packages/cli/src/common/constants.ts (1)
1-6: Good centralization of environment variable constantsCreating this constants file is a good practice for centralizing and standardizing environment variable names. The naming convention clearly distinguishes between internal variables (prefixed with underscore) and user-facing ones, which helps prevent naming conflicts and makes the code more maintainable.
packages/cli/src/cli/commands/dev.ts (6)
12-13: Enhanced hot module reloading key regexThe updated regex properly expands HMR to include
presetandpresets.*keys, which aligns with the PR objective to improve hot-reloading of configuration values. This will ensure that changes to these keys trigger appropriate updates without unnecessary rebuilds.
82-82: Improved log readabilityAdding a newline character to the config update log message improves readability by formatting the diff entries as a list rather than a single line, making it easier for developers to identify what changed.
86-87: Clearer documentation of hot reload behaviorThe updated comment provides better clarity about what hot reloading actually does - updating runtime values and restarting indexers without rebuilding. This helps other developers understand the system behavior.
95-97: Properly await reload in restart hookMaking the restart hook callback async and awaiting the reload function ensures that the reload process completes before continuing, preventing potential race conditions or incomplete reloads.
117-117: Better sequencing of restart log messageMoving the "Restarting indexers" log message to after killing the child process makes the log sequence more accurate and helps developers better understand the actual flow of operations.
144-148: Appropriate log level for process exitChanging to
apibara.logger.infofromapibara.logger.logis more semantically appropriate for this type of operational message, maintaining consistent logging practices.
jaipaljadeja
changed the title
2 participants
runtimeConfigdata flow in cliruntimeConfigvalues not being updated on changes toapibara.configduringdevmoderuntimeConfig,preset&presetvalues inapibara.config, we only refresh these values and restart indexers without any re-build step (restarts before you could blink)@apibara/indexermodules fromapibaracli package as submodules for better UXapibarasubmodules instead of@apibara/indexerpackage.clientOptionsindefineIndexerto override client options.